Hospital Information Management PDF

MBA
(DISTANCE MODE)
DBA 1757
HOSPITAL INFORMATION SYSTEM
III SEMESTER
COURSE MATERIAL
Centre for Distance Education

Anna University Chennai
Chennai – 600 025
Author
Mr.V
Mr.V.M.Shenba
.V.M.Shenba
.M.Shenbagg ar aman Mr.R.W
.R.Wrr anton P
Mr.R.W er
Per
ereez
Assistant Professor Assistant Professor
SRM School of Management I.T. Department
SRM University Sardar Vallabhbhai Patel Institute of
Kattankulathur - 603 203 Textile Management
Coimbatore - 641 004
Reviewer
Mr.A.K.Sheik Manz
Mr.A.K.Sheik oor
Manzoor
Lecture
Department of Management Studies
Anna University Chennai
Chennai - 600 025
Editorial Board
Dr.T
Dr.T.V
.T.V.Geetha
.V.Geetha Dr.H.P
Dr.H.P eer
.H.Peer
eeruu Mohamed
Professor Professor
Department of Computer Science and Engineering Department of Management Studies
Anna University Chennai Anna University Chennai
Chennai - 600 025 Chennai - 600 025
Dr.C
.C.. Chella
Dr.C ppan
Chellappan D rr.A.K
.A.K annan
Professor Professor
Department of Computer Science and Engineering Department of Computer Science and Engineering
Anna University Chennai Anna University Chennai
Chennai - 600 025 Chennai - 600 025
Copyrights Reserved
(For Private Circulation only)
ii
iii
ACKNOWLEDGEMENT
The authors have drawn inputs from several sources for the preparation of this course material, to meet
the requirements of the syllabus. The author gracefully acknowledges the following sources:
• Strategic Hospitality Management, Teare and Boer, Cassel Publishers, 1996.

• Feedback of Hospital Personnel, Goyal RC, Prentice Hall of India, 1993.
• Laboratory Management Information Systems Concepts, Integration and Implementation, R.D.McDowall,
Sigma press, UK, 1990.
• Analysis and Dersign of Information systems, James A.Senn, McGraw HILL Publishing Company, second
edition.
• Principles of Information Systems, by Ralph.M.Stair and George W.Reynolds, Thomson learning, sixth
edition.
• Security in Computing, Charles, Lawrence, Pearson Education, Third Edition
• Management Information Systems by Kenneth C.Laudon and Jene P.Laudon, , Pearson education, Inc.
Ninth edition.
• Computer Networks, Andrew S.Tanenbaum, Prentice-Hall of India, Fourth edition.
• Database systems, C.J.Date, A.Kannan and S.Swamynathan, Pearson Education, Eighth edition.
In spite of at most care taken to prepare the list of references any omission in the list is only accidental
and not purposeful.
Mr.V.M.Shenbagaraman
&
Mr.R.Wranton Perez
Author
v
DBA 1757 HOSPITAL INFORMATION SYSTEM
UNIT I INTRODUCTION
Introduction to Healthcare Information - Fundamentals, system concepts, characteristics – Types of healthcare

information–Planning, implementing and controlling healthcare information systems
UNIT II DATA SYSTEM IN HOSPITAL
Data Sources- Various functional systems like payroll and financial systems, Human resources systems, inventory
systems-The Electronic Medical record.
UNIT III DATABASE MANAGEMENT
Significance of health data-Types of healthcare data- Database approach –Data models - Relational data model,
Hierarchical Data Model, network data model, distributed processing – Data mining and design process
UNIT IV INFORMATION MANAGEMENT
Introduction-Functional –Types of administrative and clinical information system– Functional capabilities of

computerized hospital information system – Need for computerization in hospitals – Healthcare information
Regulations, Laws and Standards- Legal aspects of managing healthcare information- security of healthcare
information system.
UNIT V DELIVERY NETWORK
Definition, changes and challenges and uses – Determining the Delivery Network needs – Delivery Network
model – Maintaining computerized healthcare databases, databases on Healthcare Institutions – Evaluation of
computerized medical records.
REFERENCES
1. Bipin C Desai. Introduction to Database design

2. Koontz O’Donnell Essentials of management
3. Kappor, V.K.Introduction to Electronic Data Processing and MIS
4. Ball, Marion J etel Strategies and Technologies for Healthcare Information Springer Publication New
York.
vii
CONTENTS
UNIT I
INTRODUCTION
1.1 FUNDAMENTALS IN HEALTHCARE INFORMATION 1

1.1.1 Introduction 1
1.1.2 Learning Objectives 1
1.1.3. Growth Of Healthcare Sector In India 1
1.2. EVOLUTION OF HEALTHCARE INFORMATION SYSTEM 7
1.2.2 earning Objectives 7
1.2.3 System And Its Characteristics 8
1.2.4. Major Types Of Systems 10
1.2.5 Healthcare Information Systems 14
1.2.6 Example Of Healthcare Software 18
1.3 PLANNING, IMPLEMENTING AND CONTROLLING
HEALTHCARE INFORMATION SYSTEMS 20
1.3.3 Planning The Healthcare Information System 20
1.3.4 Managing Healthcare Information 23
1.3.5. Impact Of Information And Communication Technology 25
1.3.6. Evaluation of ICTs in health and healthcare. 28
UNIT II
DATA SYSTEM IN HOSPITAL
2.1. INTRODUCTION 31
2.1.2 Learning objectives 31
2.1.3 Data Sources 32
2.1.4. Various Functional Systmes 34
2.2 ELECTRONIC MEDIAL RECORD 49
2.2.3. Description 49
ix
UNIT III
DATABASE MANAGEMENT
3.1 DATABASE MANAGEMENT 57
3.1.2. Learning Objectives 58
3.1.3 Data Base Management Concepts 58
3.1.4. Data Models 64
3.2 DATA MODELING 72
3.2.3. Common Data Modeling Notations 72
3.2.4 How to Model Data 74
3.2.5 Evolutionary/Agile Data Modeling 83
3.3 NORMALIZATION 85
3.3.3 Rules of Data Normalization 85
3.4 DATA MINING AND DESIGN PROCESS 94
3.4.3 Data Warehousing 94
3.4.4 Types Of Healthcare Data 105
UNIT IV
INFORMATION MANAGEMENT
4.1 INFORMATION MANAGEMENT 111
4.1.3 Types Of Administrative And Clinical Information System 112
4.1.4 Main Features And Functionalities 112
4.1.5 Functional Capabilities Of Computerized Hospital
Information System 118
4.1.6. Need For Computerization In Hospitals 122
4.1.7 Healthcare Information Regulations, Laws And Standards 124
4.1.8 Legal Aspects Of Managing Healthcare Information 128
4.1.9 Security Of Healthcare Information System 132
x
UNIT V
DELIVERY NETWORK
5.1 HEALTH CARE INDUSTRY: CHALLENGES

AND IMPLICATIONS 135
5.1.3 The Challenges In Health Care Delivery 135
5.1.4. Managerial Implications 138
5.1.5 Advance Health Care Using Computers 140
5.1.6. The Future Of Integrated Healthcare It 142
5.1.7 Smart Cards5.1.8. Delivery Network Model 143
5.1.8 Delivery Network Model 144
5.2 MAINTAINING COMPUTERIZED HEALTH DATABASES 149
5.2.1 Introductio 149
5.2.3 Maintaining Computerized Health Databases 149
5.2.4. Guidelines For Developing Electronic Medical
Records In Databases 150
5.2.5. Characteristics Of Electronic Medical Record 151
5.2.6. Challenges And Limitations Of Electronic
Medical Record In Databases 153
5.2.7 Practice Guidelines For Health Information
And Record Systems 154
5.3 EVALUATION OF COMPUTERIZED MEDICAL RECORDS 161
5.3.3 Guidelines For Computerized Patient Record Entries 162
5.3.4 Electronic Medical Record 163
5.3.5 Risks In Computerized Medical Information System 167
5.3.6 Models And Frameworks Commonly Used For Evaluation 168
5.3.7 Future Efforts To Evaluate Complex Health Information Systems 170
5.3.8 Evaluation Of Complex Health Information Systems 171
xi
NOTES
UNIT I
INTRODUCTION
CHAPTER 1
1.1 FUNDAMENTALS IN HEALTHCARE INFORMATION
1.1.1 Introduction
Healthcare is one of India’s largest sectors, in terms of revenue and employment, and
the sector is expanding rapidly. During the 1990s, Indian healthcare grew at a compound
annual rate of 16%. Today the total value of the sector is more than $34 billion. This
translates to $34 per capita, or roughly 6% of GDP. By 2012, India’s healthcare sector is
projected to grow to nearly $40 billion. The private sector accounts for more than 80% of
total healthcare spending in India. Unless there is a decline in the combined federal and
state government deficit, which currently stands at roughly 9%, the opportunity for significantly
higher public health spending will be limited. In this scenario, Healthcare Information system
is much essential for providing accurate, reliable and up-to-date information for better
decision making.
1.1.2 Learning Objectives
Upon successful completion of this unit, you should be able to

• Understand the Health administration system in India
• Learn the Growth of Healthcare sector
• Understand the importance of Healthcare
• Visualize the Deteriorating Infrastructure
1.1.3 Growth Of Healthcare Sector In India
1.1.3 (i). Health Administration System in India
After independence, India has made considerable progress in economic and social
development. India has invested huge sums of money in the development of extensive
health care system India, compared to other developing nations spends slightly higher
amount in the health sector. It spends 6% of the GDP in the health sector. However, many
of the key health indicators are very low, communicable diseases continue to be a major
1 ANNA UNIVERSITY CHENNAI

DBA 1757
problem; maternal mortality is high; and morbidity especially among the poor exacts a high
NOTES toll. Even these indicators vary from region to region significantly.
Organization of Health Care Administration in the Country Ministry of health and

Family Welfare is the apex executive organization dealing with the issues of Health and
Family Welfare in India. Health is the state subject in India and the Ministry of Health and
Family welfare acts as a Coordinator between the state Health departments, Planning
commission, central council of Health etc. besides implementing various national programs
and items under unions list and concurrent list. In the process it is aided by the Directorate
General of Health Services.
Health administration at the apex level of the Government of India consists of Secretary
for health and Secretary for Family Welfare supported by Additional, Joint secretaries
who are drawn from the Indian Civil Service. The rest of the organization is mostly program/
project based. Adhoc project structures such as TB project or Malaria project etc., are
created as and when necessary. Since state governments implement the projects and deliver
the regular health services they have fairly well demarcated systems. Separate directorates
or head offices usually exist at the state capital for primary, secondary and tertiary health
care which includes medical colleges and medical education. Many states have separate
structure for family welfare operations since population control through family planning is
given great importance. An average Indian State will have 10 to 25 districts where from
most of the revenue and civil administration is governed. District health administration
consists of number of officers and doctors who on an average handle 10 to 15 hospitals,
30 to 60 primary health centers and 300 to 400 sub centers.
1.1.3 (ii). Growing Healthcare Sector
One driver of growth in the healthcare sector is India’s booming population, currently
1.1 billion and increasing at a 2% annual rate. By 2030, India is expected to surpass China
as the world’s most populous nation. By 2050, the population is projected to reach 1.6
billion. This population increase is due in part to a decline in infant mortality, the result of
better healthcare facilities and the government’s emphasis on eradicating diseases such as
hepatitis and polio among infants. In addition, life expectancy is rapidly approaching the
levels of the western world. By 2025, an estimated 189 million Indians will be at least 60
years of age—triple the number in 2004, thanks to greater affluence and better hygiene.
The growing elderly population will place an enormous burden on India’s healthcare
infrastructure. The Indian economy, estimated at roughly $1 trillion, is growing in tandem
with the population. Goldman Sachs predicts that the Indian economy will expand by at
least 5% annually for the next 45 years and that it will be the only emerging economy to
maintain such a robust pace of growth.
The following table shows the % of middle class population in India

NOTES
SOURCE: CRIS Infac, 2005
India traditionally has been a rural, agrarian economy. Nearly three quarters of the
population still lives in rural areas, and as of 2004, an estimated 27.5% of Indians were
living below the national poverty line. Some 300 million people in India live on less than a
dollar a day, and more than 50% of all children are malnourished
However, India’s thriving economy is driving urbanization and creating an expanding

middle class, with more disposable income to spend on healthcare. While per capita income
was $620 in 2005, over 150 million Indians have annual incomes of more than $1,000,
and many who work in the business services sector earn as much as $20,000 a year.
While this is a fraction of the income that their US peers earn, it is the equivalent of more
than $100,000 per year when adjusted for purchasing power parity. More women are
entering the workforce as well, further boosting the purchasing power of Indian households.
Between 1991 and 2001, the percentage of women increased from 22% to 26% of the
workforce, according to the latest Indian government census. Many of these women are
highly educated: the ratio of women to men who have a college degree or higher level of
education is 40:60. Thanks to rising income, today at least 50 million Indians can afford to
buy Western medicines—a market only 20% smaller than that of the UK. If the economy
continues to grow faster than the economies of the developedworld, and the literacy rate
keeps rising, much of western and southern India will be middle class by 2020.
1.1.3 (iii).Importance of Healthcare
Another factor driving the growth of India’s healthcare sector is a rise in both infectious
and chronic degenerative diseases. While ailments such as poliomyelitis, leprosy, and
neonatal tetanus will soon be eliminated, some communicable diseases once thought to be
under control, such as dengue fever, viral hepatitis, tuberculosis, malaria, and pneumonia,
have returned in force or have developed a stubborn resistance to drugs. This troubling
trend can be attributed in part to substandard housing, inadequate water, sewage and
waste management systems, a crumbling public health infrastructure, and increased air
travel.
In addition to battling infectious diseases, India is grappling with the emergence of

diseases such as AIDS as well as food- and water-borne illnesses. And as Indians live
more affluent lives and adopt unhealthy western diets that are high in fat and sugar, the
country is experiencing a rise in lifestyle diseases such as hypertension, cancer, and diabetes,
which is reaching epidemic proportions (see sidebar, Over the next 5-10 years, lifestyle
diseases are expected to grow at a faster rate than infectious diseases in India, and to

DBA 1757
result in an increase in cost per treatment. Wellness programs targeted at the workplace,
NOTES where many sedentary jobs are contributing to an erosion of employees’ health, could help
to reduce the rising incidence of lifestyle disease
Paralleling the rise of disease is the emergence of a robust pharmaceutical industry in

India. The Indian pharmaceutical market is one of the fastest growing markets in the world;
sales increased by 17.5% to $7.3 billion in 2006, according to IMS Health. Many factors,
including a strong economy and the country’s growing healthcare needs have contributed
to the accelerated growth, which is especially strong in the over-the-counter (OTC) market.
Overall, the domestic pharmaceutical industry is highly fragmented; more than 10,000
firms collectively control about 70% of the market. Only three foreign multinationals rank
in the top 10 companies, as measured by sales, and collectively they have only 11.9% of
the market between them. But many of the local players are generics producers specializing
in anti-infective, and as the illnesses of affluence and age increase, the demand for innovative
new pharmaceuticals will rise. The federal government uses price controls to ensure that
vital drugs are affordable to the Indian population. Under the proposed pharmaceutical
policy 2006, the government revealed its intention to raise the number of essential drugs
under price controls from 79 to nearly 354, which would bring almost a third of the industry
under price controls and adversely impact foreign pharmaceutical firms that want to business
in India.2 It is an ongoing challenge to balance the commercial interests of pharmaceutical
companies with the broader social objective of curing disease and preventing epidemics
that could decimate the Indian population.
1.1.3 (iv). Deteriorating Infrastructure
India’s healthcare infrastructure has not kept pace with the economy’s growth. The
physical infrastructure is woefully inadequate to meet today’s healthcare demands, much
less tomorrow’s. While India has several centers of excellence in healthcare delivery, these
facilities are limited in their ability to drive healthcare standards because of the poor condition
ofthe infrastructure in the vast majority of the country. Of the 15,393 hospitals in India in
2002, roughly two-thirds were public. After years of under-funding, most public health
facilities provide only basic care. With a few exceptions, such as the All India Institute of
Medical Studies (AIIMS), public health facilities are inefficient, inadequately managed and
staffed, and have poorly maintained medical equipment. The number of public health facilities
also is inadequate. For instance, India needs 74,150 community health centers per million
population but has less than half that number. In addition, at least 11 Indian states do not
have laboratories for testing drugs, and more than half of existing laboratories are not
properly equipped or staffed. The principal responsibility for public health funding lies with
the state governments, which provide about 80% of public funding. The federal government
contributes another 15%, mostly through national health programs. However, the total
healthcare financing by the public sector is dwarfed by private sector spending. In 2003,
fee-charging private companies accounted for 82% of India’s $30.5 billion expenditure on

healthcare. This is an extremely high proportion by international standards.3 Private firms

are now thought to provide about 60% of all outpatient care in India and as much as 40% NOTES
of all in-patient care. It is estimated that nearly 70% of all hospitals and 40% of hospital
beds in the country are in the private sector. The healthcare divide When it comes to
healthcare, there are two Indias: the country with that provides high-quality medical care
to middle-class Indians and medical tourists, and the India in which the majority of the
population lives—a country whose residents have limited or no access to quality care.
Today only 25% of the Indian population has access to Western (allopathic) medicine,
which is practiced mainly in urban areas, where two-thirds of India’s hospitals and health
centers are located. Many of the rural poor must rely on alternative forms of treatment,
such as ayurvedic medicine, unani and acupuncture. The federal government has begun
taking steps to improve rural healthcare. Among other things, the government launched the
National Rural Health Mission 2005-2012 in April 2005. The aim of the Mission is to
provide effective healthcare to India’s rural population, with a focus on 18 states that have
low public health indicators and/or inadequate infrastructure. These include Arunachal
Pradesh, Assam, Bihar, Chhattisgarh, Himachal Pradesh, Jharkhand, Jammu & Kashmir,
Manipur, Mizoram, Meghalaya, Madhya Pradesh, Nagaland, Orissa, Rajasthan,
Sikkim, Tripura, Uttaranchal and Uttar Pradesh. Through the Mission, the government
is working to increase the capabilities of primary medical facilities in rural areas, and ease
the burden on to tertiary care centers in the cities, by providing equipment and training
primary care physicians in how to perform basic surgeries, such as cataract surgery. While
the rural poor are underserved, at least they can access the limited number of government-
support medical facilities that are available to them. The urban poor fare even worse,
because they cannot afford to visit the private facilities that thrive in India’s cities.
A widespread lack of health insurance compounds the healthcare challenges that

India faces. Although some form of health protection is provided by government and major
private employers, the health Insurance schemes available to the Indian public are generally
basic and inaccessible to most people. Only 11% of the population has any form of health
insurance coverage.
QUESTIONS:
Q 1.1..(a) Explain the Health Administration System In India.
Q 1. 1.(.b) Narrate the growth of Healthcare sector over a period of years
Q 1. 1.(.c) Why Healthcare is so important in your point of view?
Q 1. 1..(d) What are called Lifestyle diseases?
Q 1. 1..(e) Explain the importance of public health services in India.

DBA 1757
SUMMARY
NOTES
You have learned the Health administration system in India. Also you have understood
the importance of healthcare sector and its growth in India. You learned about lifestyle
diseases and the role played by public health services in India.
EXERCISES
1. Obtain the growth of healthcare sector using the internet for all the Asian countries
and compare that with India in all parameters.
2. Visit a Hospital near to your house and obtain all the data’s required for maintaining
the patients record.
3. Browse the net and obtain the names of software’s in healthcare information system
implemented in major hospitals in India.
4. Identify all the lifestyle diseases applicable in India.

CHAPTER 2 NOTES
1.2 EVOLUTION OF HEALTHCARE INFORMATION SYSTEM
1.2.1 Introduction
Over the last few decades, technological advances in Information Technology have
enabled the better gathering, processing, management and distribution of data. This results
in computerization of all medical records in almost all hospitals. This helps the doctors to
keep record of the continuous treatment given to a particular patient over a period of time.
If you are familiar with the healthcare industry, you would have noticed that large volume of
paper documents containing patient information may not get posted on the patient’s chart.
Unfortunately, this fact contributes to misdiagnosis and unnecessary expenditures for
healthcare. This market appears to be on the brink of dramatic growth. The need for wider
implementation of healthcare IT has been recognized by industry participants, industry
observers, and by both the hospitals and the government. Instead of using information
independently in prevention, diagnosis, and treatment, information should be managed and
analyzed continuously and collectively. It should then be possible to provide desirable
healthcare services scientifically based on individual physical features and social
characteristics as well. In general, for common diseases that tend to increase as a society
ages, significant individual differences can be found in the process of contracting an illness,
being ill, and getting better. The factors behind this are assumed to be personal traits and
lifestyle. Diagnosis can make use of information obtained during daily life i.e., a time series
of healthcare data such as weight and blood pressure and of lifestyle information such as
eating habits, habitual exercise, and hours of sleep. This information will enable a doctor to
determine whether a disease has been contracted suddenly or gradually over several years.
Hence healthcare information system plays a vital role in healthcare industry.
After reading this unit, you should be able to

• Identify what is a system and what are its characteristics?
• Define and analyze a system and its types
• Understand the fundamentals of healthcare information system.
• Understand the need for the Healthcare information system
• Understand the Decision Making process in Healthcare Information System
• Identify all the types of healthcare information Technology
• Learn the categories of Healthcare industry
• To know a few examples of Healthcare software

DBA 1757
1.2.3 System And Its Characteristics

NOTES
1.2.3 (i) Definition:
Let us learn the meaning of the generic term system. The word system can be defined
in any of the following manner.
A group of interacting, interrelated, or interdependent elements forming a complex

whole.
1. A functionally related group of elements, especially:

a. The human body regarded as a functional physiological unit.
b. An organism as a whole, especially with regard to its vital processes or functions.
c. A group of physiologically or anatomically complementary organs or parts: the
nervous system; the skeletal system.
d. A group of interacting mechanical or electrical components.
e. A network of structures and channels, as for communication, travel, or
distribution.
f. A network of related computer software, hardware, and data transmission
devices.
1. An organized set of interrelated ideas or principles.
2. A social, economic, or political organizational form.
3. A naturally occurring group of objects or phenomena: the solar system.
4. A set of objects or phenomena grouped together for classification or analysis.
5. A condition of harmonious, orderly interaction.
6. An organized and coordinated method; a procedure.
7. The prevailing social order
The fig 2.1 below shows a system to support decision making with coordination &
control in organizations.
Raw data to be processed to get Meaningful information

Fig 2.1
NOTES
The fig 2.2 below shows the business perspective on Information system
I.S – an organizational & management solution based on I.T to a challenge posed by

environment.
Fig 2.2
1.2.3 (ii) System characteristics
The following are the basic characteristics of any system:

• Systems consist of interrelated components (a relationship exists between
parts and the whole).
• Systems are arranged in a hierarchy
• Synergies among system components create a whole that is more than the
sum of its parts.
• System boundaries are artificial: systems are components of another larger
system. Systems can be open (influenced by their environment) or closed
(not influenced by their environment).
• Systems have inputs, processes, outputs, and feedback loops.
• The process of homeostasis acts to bring a system back to equilibrium
when it is disturbed by external forces.
• Unless energy is continually focused on this activity, the process of entropy
causes energy within a system to dissipate and become random.
1.2.3 (iii). Relationship of system to one another
Different types of systems exist in organizations. Not all organizations have all of the
types of systems described here. Many organizations may not have knowledge work
systems, executive support systems or decision support systems. But today most

DBA 1757
organizations make use of office automation systems and have a portfolio of information
NOTES system applications based on TPS and MIS (marketing systems, manufacturing systems,
human resources systems, Hospital Information Systems). Some organizations have hybrid
information systems that contain some of the characteristics of different types of systems.
The field of information systems is moving so quickly that the features of one particular
type of system are integrated to other types (e.g. MIS having many of the features of
ESS). System characteristics evolve and new types of systems emerge. Yet the classification
of information systems into these different types is useful because each type of system has
certain features that are relevant in particular situations.
QUESTIONS:
1. 2..a .What is a System?
1.2..b. Narrate the characteristics of a System.
1.2..c. How do you identify the relationship of one system to another system?
1.2.d. Draw and explain the system with feedback and control.
1.2.4 Major Types Of Systems
Information systems support different types of decisions at different levels of the

organizational hierarchy. The operational managers mostly make structured decisions, senior
managers deal with unstructured decisions and the middle level managers are often faced
with semi-structured decisions.
For each functional area in the organization, four levels of organizational hierarchy
can be identified: the operational level, knowledge level, management level and strategic
level. Each of these levels is served by different types of information systems.
The fig 2.3 below shows the various levels of information system in an organization.
Fig 2.3

Transaction Processing Systems (TPS) record daily routine transactions such as sales
orders from customers, or bank deposits and withdrawals. TPS are vital for the organization, NOTES
as they gather all the input necessary for other types of systems. Think about how one
could generate a monthly sales report for middle management or critical marketing
information to senior managers without TPS. TPS provide the basic input to the company’s
database. A failure in the TPS often means disaster for the organization. Entering the patient’s
history in the database and processing using the computer to get the required report is an
example of Transaction Processing system.
Knowledge Work Systems (KWS) support highly skilled knowledge workers in the
creation and integration of new knowledge into the company. Computer Aided Design
(CAD) systems used by product designers Architects use CAD software to create, modify,
evaluate and test their designs; such systems can generate photorealistic pictures, simulating
the lighting in rooms at different times of the day, perform calculations, for instance on the
amount of paint required. Surgeons use sophisticated CAD systems to design operations.
Financial institutions are using knowledge work systems to support trading and portfolio
management with powerful high-end PC’s. These allow managers to get instantaneous
analyzed results on huge amounts of financial data and provide access to external databases.
Office Automation Systems (OAS) support general office work for handling and managing
documents and facilitating communication. Text and image processing systems evolved
from word processors to desktop publishing, enabling the creation of professional documents
with graphics and special layout features. Spreadsheets, presentation packages like
PowerPoint, personal database systems and note-taking systems In addition, OAS includes
communication systems for transmitting messages and documents using e-mail and
teleconferencing capabilities. The front office in an hospital uses office automation system.
Management Information Systems (MIS) generate information for monitoring
performance (e.g. productivity information) and maintaining coordination (e.g. between
purchasing and accounts payable). MIS extract process and summarize data from the
TPS and provide periodic (weekly, monthly, quarterly) reports to managers.
Today MIS are becoming more flexible by providing access to information whenever
needed (rather than prespecified reports on a periodic basis). Users can often generate
more customized reports by selecting subsets of data (such as listing the products with 2%
increase in sales over the past month), using different sorting options (by sales region, by
salesperson, by highest volume of sales) and different display choices (graphical, tabular).
Decision Support Systems (DSS) support analytical work in semi-structured or
unstructured situations. They enable managers to answer “What if?” questions by providing
powerful models and tools (simulation, optimization) to evaluate alternatives (e.g. evaluating
alternative marketing plans). DSS are user-friendly and highly interactive. Although they
use data from the TPS and MIS, they also allow the inclusion of new data, often from
external sources, such as current share prices or prices of competitors

DBA 1757
Executive Support Systems (ESS) or Executive Information Systems (EIS) provide a

NOTES generalized computing and communication environment to senior managers to support
strategic decisions. They draw data from the MIS and allow communication with external
sources of information. But unlike DSS, they are not designed to use analytical models for
specific problem solving. ESS is designed to facilitate senior managers’ access to information
quickly and effectively. ESS have menu driven user friendly interfaces, interactive graphics
to help visualization of the situation, and communication capabilities that link the senior
executive to the external databases he requires.
The table 1 below shows the various types of system and its applications in an
organization.

Table 1
NOTES
The table 2 shows the characteristics of information processing in an organization.

Table 2

DBA 1757
QUESTIONS
NOTES 1. 2.4.a. Mention the major types of systems?
1.2.4.b Explain the four levels of organizational hierarchy.
1.2.4.c Explain the various levels of information systems in an organization.
1. 2.4.d .what is TPS?
1. 2.4.e What is KWS?
1. 2.4.f What is OAS?
1. 2.4.g What is MIS?
1. 2.4.h What is DSS?
1. 2.4.i What is EIS?
1. 2.4.j Explain various types of systems and its applications in an organization.
1. 2.4.k. Explain the characteristics of information processing in an organization.
1.2.5 Healthcare Information Systems
1.2.5.(i) Fundamentals of healthcare information systems
Although a great deal has been written about what we do not have, what about what
we do have? What we do have are advances in clinical informatics never before dreamed
about by our predecessors: computers that fit not just in the ‘palm of your hand’ but that
can be ingested and used as diagnostics tools. We do have the ability to communicate,
teach, and deliver care across geographical distances and time zones; and access to evidence-
based practice (EBP) guidelines and research databases 24/7. Today, invasive surgery via
robotics is a reality. All from information systems and technological tools that have been
proven to aid in the delivery of patient care, improve clinical practice, support decision-
making and decrease care delivery costs. What we do have is the ability to collect, track
and trend patient data, transform that data into information and that information into
knowledge.
We have the tools to deal with the challenges at hand. Put simplistically, we may be
overlooking our fundamentals and not working with what we do have. These fundamentals
are process redesign and change management. The limitations do not lie in the technological
possibilities but in the oversight of these fundamentals, which are required for successful
technological adoption. Many organizations are struggling because they are trying to use
technological tools without adequate knowledge. A lack of knowledge not just with the
actual technology but, more importantly, with the foundational fundamentals needed to
ensure the success of the technology’s use in practice.
New systems are put into place over existing ineffective processes within an institution.
Insufficient attention has been given to establishing the social, cultural, and practice changes
that have to precede technological initiatives. The magnitude of change required in
implementing clinical information systems, telehealth care, medication bar coding, and
computerized provider order entry (CPOE) is frequently underestimated. Without the

fundamentals in place first, unrealistic expectations are formed relating to the technology’s
ability to provide a solution. A lack of attention to the fundamentals results in costly systems NOTES
that go under-utilized. When the system falls short, the credibility of future initiatives may
also be diminished.
What we do have is the ability to re-design ineffective processes, implement evidence-

based research into practice, and proactively manage the changes. These fundamentals
serve to facilitate, promote, and bring to the hands-on clinician the tools necessary to
improve clinical practice and patient care. Without these fundamentals, we cannot thoroughly
utilize the technological tools and address the challenges our healthcare system faces today.
As you know, each person is different in both mental and physical terms. For this
reason, the main concern of any recipient of healthcare services is whether individual services
that provide therapies are truly effective “for me.” This concern is voiced without distinction
to health maintenance services (such as physical examinations and general checkups) and
medical services. There are two important concepts underlying informatics (information
science) in healthcare: EBM (evidence-based medicine), or medical care based on scientific
evidence, and personalized healthcare, or medical care customized for individuals.
With an effective health information system, we can have ready access to the health
information, enabling us to participate effectively in our healthcare decisions. Research on
pressing medical issues can be conducted more efficiently and quickly using modern health
information systems. It is not possible to have control over healthcare costs until there is
control over healthcare information. That is the fundamental thesis driving development in
the healthcare information systems industry. One important element of healthcare information
technology (HIT) is payer/provider perceptions regarding the need for information
technology. It is seen that the gap between cost control and competitive advantage has
been bridged by the understanding that investments in information technology are now of
strategic necessity.
According to the Microsoft Corporation,

• More than 20,000 health related Internet sites have been formed in recent years
• 54 percent of all Internet users regularly use the net for health related information
• 4 million patients have made at least one on-line e-health purchase, and
• 25 percent of adults visiting disease specific web-sites ask their physicians for
advertised products
1.2.5.(ii) Need for Healthcare Information System
The following are the factors which make the critical need for the implementation of IT in
Healthcare industry.
• Avoidance of medical errors
• Improvement of resource utilization

DBA 1757
• Acceleration of knowledge diffusion

NOTES • Reduction of variability in healthcare delivery and access
• Empowerment of the consumer
• Strengthening of data privacy and protection
• Promotion of public health and preparedness
Data and scientific information can be visualized in the form of graph displays, chart
displays, histograms, maps and elaborate screen images. Rapid progress has been made
in the development of visualization techniques, with three-dimensional (3-D) imaging
appearing in diagnostic medicine as well as in healthcare education. However, the effective
graphical display of information presents a number of challenges. Work is being conducted
in developing methods for determining important relationships in the large quantities of
healthcare data that could be displayed to end users and for restricting the display of
complex data to those parameters that are most relevant to the patient and/or situation
context.
1.2.5 (iii) Decision Making In Healthcare Information System
Bedside critical care monitors that are typically available often provide limited types
of display: for example, all monitored signals over some time period (e.g., the last 30 to 60
seconds) or a summary view through the last few hours or day. Research is being conducted
in transforming such numerical data into novel and concise visual metaphors. The aim is
always to avoid information overload and produce meaningful, bottom-line conclusions
that can support the decision maker rather than mere bunches of facts
1.2.5 (iv) Three Types of Healthcare Information Technology
Healthcare information technology, and for that matter information technology in any
industry, falls generally into three major types based on the problem they are developed to
solve:
Operational information technology. This group represents the core systems used to
run the business from day to day, from paying the bills, charging patients for services,
scheduling appointments, gathering patient data, handling admissions/discharges/transfers
and so forth. Healthcare as an industry is behind in exploiting the computer to manage
these everyday tasks as compared to the banking, insurance, retail, manufacturing,
transportation and communications industries. This is not news. Well, actually, this fact
makes the news every day. And our presidential candidates are making use of this news to
win votes.
Communications information technology. This technology group deals with the ability
to not only run the business using IT (i.e., operational information technology), but also

getting the right information transmitted to the right people at the right time. Once again,
this is newsworthy and resonates with voters. How many of us see a specialist after seeing NOTES
our primary care physician, only to find out that the file (often a file folder full of handwritten
paper documents) has not arrived yet? Or how many of us have spent hours on the phone
with our health plan trying to clear up a problem with our EOB (explanation of benefits) for
a service that occurred months ago? This technology need rings true with voters and therefore
gets a lot of attention in several of the candidates’ statements.
Analytical information technology. The third major technology group concerns the use
of the operational information as well as the communicated information to make evidence-
based healthcare decisions. These decisions could impact medical effectiveness, they could
affect service efficiency, or they could be strategic in nature such as which patient groups
to serve, how to serve them and why. With one notable exception (Senator Chris Dodd’s
platform), this application of information technology is hardly touched upon. This is not
surprising since analytics and analytical applications are not widely familiar to the public
and, therefore, not likely to ring up as many votes as the other two types. This situation
represents an overlooked opportunity by the presidential candidates, which I will explain
below.
1.2.5 (v) Categories in health care industry
The following table shows the various categories of healthcare industry.

Drug Treatment Center
Emergency Rooms
Elderly Care
General Healthcare Industry
Health Insurance
Healthcare Management
Hospitals
Long Term Care
Managed Care
Medicaid
Medical Billing
Medical Facilities
Medicare
Nursing Homes
Urgent Care
QUESTIONS
1. 2.5.a What is Healthcare information System?
1. 2.5.b Explain the need for Healthcare information System?

DBA 1757
1. 2.5.c What is Decision making in Healthcare information System?

NOTES 1. 2.5.d Explain the three major types of Healthcare information Technology.
1. 2.5.e Mention the categories of healthcare industry.
1.2.6 Example Of Healthcare Software
1.2.6. (i) Vista
Vista is an enterprise-wide, fully integrated, fully functional information system built

around an electronic health record. It is easily customizable and can be configured to fit
any type of healthcare organization, from clinics and medical practices to nursing homes
and large hospitals. VistA has been named one of the best healthcare information systems
in the nation by the Institute of Medicine.Developed by the Department of Veterans Affairs,
the VistA healthcare information system supports the hospitals and clinics serving veterans
throughout the United States. VistA has been deployed in thousands of healthcare facilities,
both domestic and international.Because VistA is available in the public domain, there are
no license fees to use the software. This makes VistA an affordable electronic health record
system for healthcare organizations.
VistA provides healthcare facilities with all of the tools needed to reduce patient errors,
lower costs, and improve the quality of care, including:
Computerized order entry
Bar code medication administration
Electronic prescribing
Clinical guidelines
1.2.6.(ii) Clinical Information Management Solutions provide organizations a varied

range of integrated applications that extend to all clinical departments and automate
administrative and clinical documentation tasks, enabling clinicians to focus on providing
high-quality patient care, instead of managing patient information. The flexible applications,
allow organizations to configure the system to meet the needs of their physicians, nurses,
and other care providers. The system works to encourage compliance with organizational
practices and ensure patient safety. CIM Offers nurses a single, convenient place to
document patient care. The application enables the users to directly enter the assessments
of the patients and their progress along with, vital signs, intake/ output values and the
procedures followed by the caregivers during the day. CIM improves the work management
and flow as the communication systems alerts the particular department. Users can enter
orders for all patient types (inpatients, outpatients, residents, etc.) CIM helps the healthcare
providers to verify the necessary healthcare procedures for patients based on their age,
sex, and diagnosis, ensuring patients receive consistent care for routine wellness and chronic
illness treatment. CIM provides physicians a single and clear access to patient information
at his /her convenience. Physicians can access the vital information in the patient’s electronic
medical record, place orders, print reports, and view, edit and electronically sign transcribed

documents. Allowing the physician to have a direct access to the information and functions
accessed by them everyday to treat the patients. NOTES
SUMMARY
• You have learned what is a system and its characteristics.
• You understood the types of systems in an organization.
• You studied the fundamentals of Healthcare information systems.
• You read the decision making in healthcare information system and the types of
healthcare information technology.
EXERCISES
1. Visit your nearby hospital and learn the type of computerized information system
used there.
2. Discuss with the employees in the Hospital the problems and issues in the software
implemented for healthcare.

DBA 1757
NOTES
CHAPTER 3
1.3 PLANNING, IMPLEMENTING AND CONTROLLING HEALTHCARE

INFORMATION SYSTEMS
1.3.1 Introduction
The benefits of a population with increased knowledge about health and of increased
understanding by patients of their disease are well recognized. The challenge is to assure
the quality of the information available and to ensure that the information that patients get is
accurate and appropriate.

• Know the advantages of healthcare information system
• Make the Planning for the Healthcare Information System
• Understand the implementation procedure of healthcare information system
• Learn how to maintain and control the healthcare information system
1.3.3 Planning The Healthcare Information System
The effective health information system provides the following advantages.

• Improved patient safety
• Improved quality of care
• Improved clinical and administrative efficiency
• Improved detection of epidemic threats, both natural and man-made
• Cost savings
• Healthcare consumer empowerment through improved access to their
• personal health information
• Adaptable disaster preparedness systems
• Advancements in public health and medical research
1.3.3.(i). Planning for the healthcare information system
An iterative process is especially important in the Design and delivery of large and
complex systems. Information and communication technology are likely to fail if their design
is not based on how People work together. Healthcare professionals know how specific
problems in their area of expertise are addressed, what the structure of the overall patient
pathway is and how test results are used and communicated throughout the healthcare
system. Clearly identified user requirements will allow appropriate criteria to be determined

that will be used to evaluate the technical, financial and user-satisfaction aspects. It will be
impossible to determine the success of a new system without having such evaluation criteria NOTES
It is often difficult for users to imagine how future systems will operate. It is much easier for
users to respond to systems they see and work with. Therefore emerging Information and
communication technology should be designed with a willingness to try something, see if
it works, keep successful aspects and abandon unsuccessful ones, then start again.
The experimentation is both with technology and with how people function together.
Provision should be made to enable locally developed Information and communication
technology to be introduced gradually into the healthcare system Seed money is essential
for initial development work to fund small trials of experimental models, develop prototypes
and new methodologies. This should be funded by the state governments and central
governments and corporate.. The results of this work need to feed into health service
planning and can help to define user specifications more clearly. Industry and the Department
of Trade and Industry need to be involved in the commercialization of new healthcare
Systems. This local experimentation needs to be undertaken within centrally set standards
to ensure interoperability. A key role for the national IT programme is essential to ensure
that all stages of the development are undertaken within standards to ensure interoperability.
It is essential that all healthcare professionals and their professional bodies are involved in
the design specification, implementation and evaluation of healthcare systems, and that
healthcare managers ensure that they have sufficient time to do so.
1.3.3. (ii). Implementation procedure of healthcare information system
The introduction of healthcare information system can change professional roles and
relationships. Importantly, it can also affect the organisation of clinical work. In this section
we highlight factors that determine whether the implementation of healthcare information
system is successful or not. Evaluation and feedback are also key parts of managing the
introduction of healthcare information system New information technology can improve
patient care or enhance professional roles by transforming clinical practice, mitigating the
shortage of health professionals or enhancing job satisfaction. However, healthcare
professionals are more likely to resist the introduction of information technology if they
believe that it inhibits their ‘clinical judgment’ and adversely affect the professional–patient
relationship.
Example
Nurses access to computers and the internet at work is still limited
Eligible organizations include a comprehensive list of healthcare professionals:

1. Hospitals
2. Physicians
3. Primary Care Practitioners

DBA 1757
4. Secondary and Tertiary Providers
NOTES 5. Long Term Care
6. Rural Health Centers
7. Rural Health Networks
8. Health Plans
9. Pharmacies
10. Clinical Laboratories
11. Diagnostic Testing Centers
12. Public and private
It is also essential to have clear goals and purpose when introducing new technology
in healthcare. These goals should encompass high-level organisational aspirations as well
as local clinical needs or goals. They should also be transparent to both the wider organisation
and the local users. Examples of these are given below.
• Provide seamless service.
• Break down boundaries between institutions and providers
• Give more autonomy to individual groups.
• Ensure interoperability of services, devices, data streams and external information
sources.
• Provide better communication between healthcare professional and patient.
• Help patients to manage their health and healthcare.
• Provide better information services.
• Support self-care , eg. linked in with sensors at home.
• Giving patients more options about how, when and where they receive treatment.
• Ensure patient data available to professionals is complete, consistent, relevant,
up-to- date and accessible quickly in emergencies. This would also support
consistent evidence-based medicine and permit tailored services.
• Provide a better evidence base for providers to make decisions.
• Collect massive datasets on public health.
• Provide relevant data to allow more informed budget decisions
1.3.3. (iii) Training and Support Needs
The introduction of new ICTs requires healthcare professionals to be equipped with

the necessary understanding of the concepts behind the systems as well as the skills to use
specific new technologies. In addition, new systems will require support once they are
introduced. This education, training and support must be taken into account when
determining the full costs of introducing new technology. The basic training and continuing
professional development for healthcare professionals needs to integrate the use of IT into
everyday professional practice. This goes beyond basic IT skills such as being able to use
word processor and spreadsheet software packages to include the ability to operate
effectively in an information society. Training in IT needs to be practical and able to be
incorporated into mainstream activities. Such training also needs to be flexible so that it can
be tailored to the particular needs of different health professionals. This is an area where

the health informatics community could assist in curricula development and competency
frameworks. There has been a considerable amount of work on identifying the required NOTES
training competencies and methods to assess these competencies.
Hands on’ training programme are required as well as allowing time for professionals
to become competent at using any new systems. Opportunities for regular use of IT are
needed to ensure user competence. Additional learning materials, from written materials to
other forms of self-help guidance, should be made available The training and development
for healthcare professionals needs to be broader and includes the following:
• Understanding how to find the most reliable sources of information from the ever
- growing number of publicly available sources;
• Guiding patients through publicly available information sources;
• Incorporating use of IT into patient consultations;
• Quick and accurate data entry at the point of care;
• Understanding decision support processes;
• Extracting data to support decisions and monitor the outcomes of practice;
• Understanding the role of technology in the delivery and organisation of care;
• Training other users, such as patients and carerss, how to use IT. It is essential that
healthcare professionals are given training and support on how to use new specific
IT when they are introduced. Ongoing access to technical support is essential so
that difficulties can be addressed quickly. With the expected increase in patient-
led care, patients and their carerss will also need to be trained and have access to
technical support. It is also important that experts in IT working in the healthcare
arena have a good understanding of the challengesfacing the healthcare service,
healthcare professionals, patients and carerss. Thegrowing community of health
informatics professionals are well-placed toprovide training and support to experts
in IT moving into the health andhealthcare areas.
Questions
1.3(a).Explain the planning procedure for the Healthcare information System.
1.3.(b).Narrate the implementation of Healthcare information System.
1.3.(c).Point out the Training and support needs for Healthcare information System.
1.3.4. Managing Healthcare Information
User requirements need to be very clearly identified at the start to prevent the initial
scope either being extended or having new components added. This results in cost and
time overruns and can result in project failure in the worst cases.
The Experts in IT traditionally come from a different domain and have different skills.
It is essential that those involved in developing new IT work closely with users (health
professionals, patients and carers) and interdisciplinary working should be encouraged.
DBA 1757
1.3.4. (i) Clear goals in introducing new IT in healthcare

NOTES
IT are more likely to be embraced and successfully implemented if they are introduced
because of clinical pull rather than technology push.
1.3.4.(ii) Clinical governance and data protection
Clinical governance is the system through which healthcare organisations are

accountable for continuously improving the quality of their services and safeguarding high
standards of care, by creating an environment in which clinical excellence will flourish. It
aims to minimize risk and improve clinical effectiveness. The IT and the way they are used
by health professionals should be the subject of scrutiny. Therefore healthcare delivered
using IT should be subjected to audit so that variations in the process and in access to
healthcare as a result of using IT are minimised. IT also have the potential to promote
clinical governance by providing access to good information about the quality of services,
thereby promoting continuous quality improvement. IT should increase opportunities for
patients to participate in their care, but how such information is accessed and used and by
whom are key governance issues. Confidentiality and data protection are major concerns
in relation to the more widespread use of IT, as health data are particularly sensitive. It is
also important to ensure that good practice relating to IT is adopted appropriately. As
stated above, health data are sensitive. Rigorous mechanisms are needed for access control.
The mechanisms should take into account the role, team and organisation of those involved
and their relationship with the patient.
1.3.4.(iii) Privacy and confidentiality
Flexibility and ease of use must also be weighed against privacy concerns. The delivery
of healthcare is always performed under significant time constraints, so any confidentiality
guidelines for healthcare professionals must ensure that dealing with confidentiality issues
does not take up so much time that they detract from the delivery of care. Trust between
healthcare professional and patient is a complex issue. Part of that trust is due to healthcare
professionals keeping patients’ sensitive data confidential. However, concerns about privacy
of personal data need to be weighed against personal and wider public health benefits of
sharing data Further investigation is needed into the degree that patients would be willing
for their personal data to be shared for wider, societal benefits.
1.3.4.(iv) Responsibilities, Processes and Liabilities for decision making
The introduction of new technologies raises issues relating to responsibilities, processes
and liabilities for decision making. IT can lead to the distribution of responsibility for treatment
across several healthcare professionals, creating uncertainties over proper clinical governance
of the patient. The liability associated with treatment must make both clinical and legal
sense. However, new computer-aided decision support systems are often based on a
single decision maker because of the need to identify an individual who might be held

responsible were treatment to go wrong. This assumption is not borne out by the realities
of shared clinical oversight in wards or elsewhere. Both of these issues can work against NOTES
uptake up of new technologies, as they may compromise trusting relationships among staff
and between staff and patients. It is easy to put this down to professional resistance but
these concerns are quite understandable • Failure to adopt IT might be seen as negligent.
Where the most effective and appropriate means of delivering a quality service to patients
is the use of IT, for example where electronic medical records may decrease prescribing
errors, then failure to adopt such measures may be held as negligent. Consequently, it may
become harder to defend non-utilisation if IT become more ubiquitous in healthcare.
IT should be able to provide an audit trail for the actions undertaken by healthcare
professionals.It should be noted that any legal action would require very robust evidence
that will stand up in court. Healthcare is increasingly being delivered by multidisciplinary
teams of professionals, so that it is not always clear whether a specific individual is responsible
or liable. IT will facilitate multidisciplinary team working, which may accentuate this problem.
Questions
1.3.4.(a). Mention the broad goals for the introduction of new Information and
communication technology in Healthcare.
1.3.4.(b).What do you mean by clinical governance and data protection.
1.3.4. (c).Define Privacy and confidentiality.
1.3.4. (d).What is decision making?
1.3.5. (e).Impact of Information and communication technology( ICT) on patients,
carers and healthcare professionals
1.3.5. Impact Of Information And Communication Technology
ON PATIENTS , CARERS AND HEALTHCARE PROFESSIONALS.
The Proliferation of Information and communication Technology on Health Care
Information System plays a significant role in todays’ competitive environment.
Let us discuss the impact of Information Technolgy on Healthcare Sector.
1.3.5.(i). ICTs in The Professional-Patient Consultation
Some practitioners fear that ICTs will interfere with the professional–patient relationship
and are already using this argument to resist the introduction of ICTs, especially in respect
of documentation during the consultation. Professionals are reluctant to do anything that
could damage the delicate balance of a consultation. A good bedside manner is often seen
as the mark of a ‘good’ doctor or nurse. It is also known that the skill with which such
encounters are handled can have a significant impact on the outcome of the care being
given.

DBA 1757
The insertion of a computer terminal into the clinician–patient encounter can be damaging.
NOTES There is evidence that, in the early days of general practice computing, patients felt that the
doctor was more interested in the computer than in them. Experience shows that the successful
use of ICTs in a healthcare consultation depends on the professional’s communication skills.
For example, the professional with good communication skills who routinely uses a lot of eye
contact will find handling ICTs is no different from handling paper. However, this requires that
the device is appropriate for the particular environment and that the professional is confident
with its use, which requires training and experience. The device must be as familiar and easy
to use as a mobile ‘phone has become to most people.
However, if the professional has poor communication skills (eg if when using paper
he or she looks more at the paper than at the patient), ICTs may actively (albeit
unconsciously) be used as a ‘protective’ barrier. Communication may be altered by use of
ICTs, with both sides perceiving barriers to communication that were not previously present.
Clinicians may find that use of ICTs shapes their encounters with patients in different ways
from usual. In particular, use of ICTs may demand reciprocal adjustments by both healthcare
professional and patient about their expectations of the consultation and their behaviours
within it. These adjustments may take several forms: for example the use of
videoconferencing technologies may require more interaction by participants than in a face-
to-face consultation. Clinicians have to examine which current practices can continue to be
used with new ICTs and where new practices will need to be developed.
1.3.5.(ii) The balance of power
The most important way in which ICTs will change professional–patient relationships,
however, is in the changed balance of power which the increase in the patient’s information
will bring. Greater access to information is already bringing a fundamental change in
healthcare delivery, from a system driven by the provider to one driven by the consumer.
With greater information available to the patient, much of the mystique of professional
practice will disappear. Some professionals may see this as a threat. Others will use it as an
opportunity. Some patients will welcome it, but, for others, the increased awareness of
uncertainty may create greater vulnerability. Both patients and clinicians will need to develop
new skills in managing patient–professional relationships.
To become useful, information requires interpretation. This creates the potential for a
‘new’ role for the nurse as a ‘knowledge broker’, helping patients access the information
they need and to decide how to use it. Nursing and allied healthcare professionals aim to
teach patients about their disease and to help them understand information about specialists,
resources and alternative treatments. To achieve this, nurses will continue to need highly
developed listening, communication and teaching skills and a clear understanding of the values
and ethical principles on which such choices will be based. Research in the USA has shown
that patients, although keen on gaining information from the worldwide web, prefer sources
that have the endorsement of their clinicians. The electronic generation of patient advice

leaflets can be used to tailor advice to the individual patient’s unique circumstances, which
research has shown to be more effective than generic pre-printed material. NOTES
1.3.5.(iii). Physical Co-location
Patients greatly value the physical presence of healthcare professionals, both for
consultation and, even more importantly, when they need direct care. Patients describe
‘being there’ as an important therapy and their view is well supported by research. It is
identified that the personal contact with healthcare professionals is very important to them.
They feared ICTs might diminish opportunities for such contact to occur. There are many
potential benefits to patients of using technologies like videoconferencing and telecare, for
remote consultations and monitoring, such as giving access to a wider range of expertise
and reducing travelling or waiting times. technological developments will make
videoconferencing vastly superior compared with what it is today. The complete substitution
of ‘virtual’ or ‘remote’ healthcare services for the physical and social interaction with a
human healthcare provider is not suitable for all situations. However, telemedicine can be
used as one component in long-term care or chronic disease management because of its
ability to increase greatly the quantity and quality of data gathered on changes to an
individual’s health status. These data can be used to improve the targeting of therapies and
provide more timely intervention.
1.3.5.(iv). Communication Overload
The volume of health information is increasing dramatically. No healthcare professional

can be expected to know all the relevant information. ICTs may help healthcare professionals
to receive the appropriate information in a digestible manner at the appropriate time. It is
possible that the huge number of protocols, guidelines, research findings and knowledge
sources, which are often duplicative and sometimes conflicting, and which are already
developed and being strongly promoted in the name of ‘evidence-based practice’, will
simply ‘turn off’ the professionals who should be using them. This could be avoided by
ensuring that health information is ‘quality assured’ to present it in a form that health
professionals (and other people) will experience as easy to use.
1.3.5.(v) Changing Professional Boundaries
The greater availability of medical information and best practice could allow fewer
skilled staff to handle more patients. The development of practice nurses, nurse practitioners
and ancillary staff has already shown that such a shift can be achieved. It is important to
note that only a suitably trained healthcare professional will be able to make the judgment
required to interpret and make decisions based on the findings, although ICTs can certainly
assist in this as well. Standardised algorithms and protocols might enable less skilled
professionals (and the patients themselves) safely and effectively to diagnose, treat and
monitor many clinical conditions, including some which are less common.

DBA 1757
1.3.5.(vi). Impact on Carers

NOTES
Carers may express concern about the practicalities and the aesthetics of technology
in the home, such as security, maintenance, cleaning, insurance and appearance. Some of
the issues facing health professionals will also face carers. For example, carers might need
training to use equipment in their homes. In such cases, carers will need appropriate training
and support to operate monitoring and assistive technologies and administer treatment at
home.
For example, ICTs that raise an alarm will need to have clearly assigned responsibilities
among patients, carers and healthcare professionals for taking action. ICTs have the potential
to help carers with several of the challenges that they face.
Example is the role that telecare can play in helping to manage the risks of caring for
people outside the controlled environment of the hospital or other care institutions However,
it is noted that the benefits of telecare have not yet been fully realised for vulnerable people
and for the wider care system.
1.3.5.(vii). Ensuring equity of access
There will remain a substantial proportion of the population who either have no desire
and/or no ability to empower themselves, through the support of ICTs, to control or even
to influence their own healthcare circumstances. Some groups of people will be less able
than others to access or to exploit available information technologies: elderly people; poor
and socially deprived people; people who cannot read; non-English speakers; the ‘IT
illiterate’ (ie those without basic IT skills); and people with sensory deficits. There have
been several studies looking at access to ICTs and the internet.
Questions
1.3.5(.a).Explain the Impact of Information and communication technology( ICT) on patients,

carers and healthcare professionals
1.3.6. Evaluation of ICTs in health and healthcare
Several systems have been evaluated, including telemedicine e-health systems , health
informatics services and clinical information standards. Given the growing importance
placed on evidence-based medicine, it is crucial to have evidence to demonstrate the
efficacy (or not) of different ICTs in different contexts.
1.3.6.(i). Identifying , Measuring and Valuing benefits of ICTs
ICTs have the potential to improve health outcomes. For example, quicker data-
handling and more accessible healthcare data may result in faster health decisions and
action, potentially saving lives and improving quality of life. Non-health outcomes are also
likely to be influenced.

Example: The amount of information that will be available to patients and healthcare
professionals may have positive and negative effects,. Telemedicine is likely to reduce NOTES
waiting times and travelling times. ICTs could help to facilitate the move towards treating
patients in the community rather than in hospital. It is therefore essential that funders invest
in evaluations that take account of standard outcome measures ranging from re-admission
rates to quality of life. Current evaluations are clearly limited and more research exploring
public perspectives of the limitations of ICTs in healthcare is therefore merited. The economic
concept of ‘opportunity cost’ assumes that resources are scarce and that every time
resources are used in one way, the ‘opportunity’ of using them in other beneficial activities
is given up. The opportunity cost of any technology is therefore defined as the benefit
forgone from not using that resource in its best alternative use. Only if a resource has a
next best use does it have an opportunity cost.
1.3.6.(ii) Staffing Costs
Staffing costs often comprise the largest component of healthcare resources. Time
invested by managers, administrators, medical professionals, health workers and clerical
staff in the planning, implementation and use of the ICTs must be accounted for. In addition
there will be staff costs associated with running and maintaining the healthcare ICTs. Training
costs are also likely to be incurred.
1.3.6.(iii) Capital Items

Capital items are clearly important in the area of ICTs. Costs will include the hardware,
system and applications software and network / telecommunications infrastructure, as well
as any capital or equipment costs of maintenance. Despite an initial outlay, the opportunity
costs of capital should be spread over time. This is accounted for by spreading the opportunity
cost of capital assets over the number of years of life judged to be relevant. Depending on
the perspective of the study, costs to patients, their families and their friends may also be
included in an evaluation. These costs may be both in terms of time and money. For example,
time and money costs may be saved in using telemedicine rather than travelling to a central
location.
1.3.6.(iv) Long-term issues
When policy-makers choose to support and deploy certain healthcare ICTs rather
than others, these choices will have a major impact over the longer term in creating a
technological ‘path dependency’ that closes off other options over time. This means that
once Connecting for Health is stabilised as a working system and standards are in place, it
will not be easy to switch from one configuration to another. This is why it is important to

DBA 1757
interdisciplinary teams will be particularly useful and should therefore be encouraged. Such
NOTES teams should include researchers from diverse backgrounds, including healthcare
professionals, computer scientists, engineers, health informatics specialists, sociologists,
anthropologists, economists, psychologists and those from business and management
backgrounds.
1.3.6.(v). Realising the potential of healthcare ICTs
Healthcare ICTs are an important tool to deliver better healthcare by either enhancing
existing processes or generating new capabilities. The technologies have the potential to
transform healthcare delivery in many ways and address future health challenges, such as
allowing individuals with chronic conditions to monitor and in some cases manage them
more effectively. It is essential that these technologies are integrated into the healthcare
delivery systems and are part of the delivery of better patient care. Consequently funding
of properly designed and implemented healthcare ICTs will be directly helping to improve
patient care. Realising these benefits requires a culture where everyone involved in healthcare
recognizes the potential value of healthcare ICTs in delivering better healthcare.
QUESTIONS
1.3.6.(a).How do you do Measuring and valuing benefits of Information and
Communication Technology in Healthcare?
1.3.6.(b).Explain the various costs involved in Healthcare information system.
SUMMARY
You have learned the Planning the Healthcare information system.Also you understood
the how to manage Health care information .you understood the costs involved in health
care information system. Also you learned the role of information technology in improving
the healthcare information system.
EXERCISES
1 Browse the net and obtain the relevant information regarding implementation
procedure of healthcare information system in a major hospital in a nearby city.
2 Visit a nearby hospital and discuss with the employees relating to the issues faced
by them after the implementation of Healthcare information system.

NOTES
UNIT II
DATA SYSTEM IN HOSPITAL

CHAPTER 1
2.1. INTRODUCTION
You meet someone in a computer store. As a knowledgeable IT professional, you

want to help this person. He says he is looking for database software to keep the names
and addresses of his customers to do his mailings and billings. But what he really needs is
a mail-merge program.
You call your travel agent to make your airline reservations for the vacation you have been
waiting for all year. The agent responds by saying that he cannot do that just now because the
system is down. She really means that the reservations computer system is not working.
Here is one more. You call your cellular phone company to complain about errors on
the latest billing statement. The phone company representative says that the automated
data system must have printed some incorrect numbers. What the representative really
implies is that the billing application has miscalculated the charges.
All the above examples show that data plays an important role for any decision making
or for getting any reports. This concept is very much required for the maintenance of
patients data in any hospital.
2.1.2. Learning objectives

• Understand the concept of data, its evolution and use of data in a system.
• Learn the various functional systems like payroll and financial systems, Human
resources systems and inventory systems

DBA 1757
2.1.3. Data Sources

NOTES
Healthcare executives require large amounts of information to determine where they
are and where they want their organizations to be in areas as diverse as patient safety,
financial performance and operational efficiency. Quantitative information is critical to
defining which areas need to be focused on to have the most impact with the least amount
of time and resources.
This is more than just a theoretical argument: If only one or two patients a year develop
infections while in the hospital, as opposed to dozens who develop pressure ulcers, chances
are that decision makers are going to want to make fixing the latter problem a top priority.
However, without reliable data, it’s almost impossible for senior managers to have the
facts they need to make these kinds of determinations and identify the parts of their operations
where they want to focus their efforts.
2.1.3.(i). Evolution of Data Systems
How were companies running their business before computers came into use? Even
at that time, organizations needed information to execute the business processes, sell goods
and services, and satisfy the needs of customers. Manual files supported business operations.
Accounting personnel performed manual calculations and prepared invoices. Payroll
departments manually did the tasks successfully. Business operations were reasonably
satisfactory. When computers were introduced in the 1960s, computer file systems replaced
the manual files. This marked a significant leap in the way data was stored and retrieved for
business operations. Here are the few progress in the usage and implications of data.
Data Processing Applications (DP). In the early days of computing, computer departments
built applications just to replace clerical labour. Mostly, these applications performed simple
accounting and financial functions. These applications produced straightforward reports. Speed
and accuracy of the computer in performing calculations were the primary factors. Computer
systems stored and retrieved data from magnetic tapes and earlier versions of disk drives.
Applications used sequential or flat files to organize data.
Management Information Systems (MIS). In the next stage, growth of technology manifested
itself in applications that went beyond accounting and finance to supporting the entire core
business of an organization. Applications began to appear to process orders, manage inventory,
bill customers, pay employees, and so on. Organizations depended on their management
information systems for their day-to-day business. Storage and retrieval of data mostly depended
on hard disks. Many applications adopted the use of database technology.
Decision-Support Systems (DSS). Further technology growth in processor speed, storage
media, systems software, and database techniques pushed the application types to systems
that supported strategic decision making. These applications are not meant for supporting
day-to-day operations of a business but for providing information to executives and managers

to make strategic decisions. In which markets should the company expand? Where should
the next distribution warehouse be built? Which product lines should be discontinued? NOTES
Which ones should be boosted? These applications dealt with sales analysis, profitability
analysis, and customer support. Decision-support systems made use of improved storage
facilities and newer features of database technology.
Data Warehousing (DW) and Data Mining (DM) Systems. In recent years, with the
enormous progress in processor scalability, mass storage, and database methods,
organizations are able to forge ahead with their applications, especially in building data
warehousing and data mining systems. These recent decision-support systems, much more
sophisticated than earlier attempts, require large volumes of data and complex analytical
techniques. These systems need large databases specially designed and built separately
from the databases that support the day-to-day operational systems.
Now, the questions in your mind would be - What has been really happening from
that time until now, when database systems have become the norm?, What prompted the
progress toward database systems?
In defining a DBMS it is important to distinguish between the two terms, data and
information, which are often used interchangeably. Data may be defined as the basic facts.
For example, a glucose value may be 97 mg/dL. This number is representative of data. On
the other hand, information may be defined as data that have been processed in some
fashion and presented in a manner that may make it useful in decision making. Simply
displaying the number 97 really has no meaning for the user. But when it is identified as a
glucose level it becomes useful information that may be utilized.
To efficiently present data to a user so that it can be informative, requires much more
than simply storing a number in a data file. In a DBMS each data item must have a description.
This information is stored in a data dictionary. The data dictionary is a major component of
any DBMS. Data definitions include all the attributes of a data item. An attribute is simply
a property such as the length of an item, an upper or lower limit, format, type, and name.
To store data on a computer system, the system must know how large or how many
characters are in the occurrence of a data item to reserve enough space for storage. By
predefining this information in the data dictionary, the DBMS will always have the appropriate
amount of storage space available.
The data dictionary is not only where data definitions are stored but also where all
data relationships are stored. Data relationships are a major component of a DBMS. A
data relationship or association is a logical and meaningful association between two or
more data items. There are basically three types of associations that can exist between
data items. These are described as one-to-one, one-to-many, and many-to-many.

DBA 1757
A one-to-one association means that for a given point in time, a value of one data item
NOTES is associated with only one value of another data item. That is, a patient’s identification
number will relate to only one patient name. It is important to have this type of relationship
because of the need to have a unique identification method as is discussed later.
In a one-to-many association a data item may have more than one value of another
data item associated with it at each period in time. A patient identification number may be
linked to several different hemoglobin values. This allows the user to view the progress of
a patient through a time span.
The third type of association results from the fact that reverse associations may exist.
In a many-to-many association at a given point in time, a single patient may actually have
more than one physician while at the same time a physician will most certainly have more
than one patient.
Improvements in technology have not only given doctors better tools to treat their
patients one-on-one, but have also dramatically changed how healthcare practitioners and
organizations can access and analyze data to improve their overall quality of care and
financial condition. Instead of having to dig through thousands of files and documents to
find the proverbial needle in the haystack, forward-thinking healthcare and physician
executives can now use advanced analytic tools to improve clinical performance.
QUESTIONS
2.1.3 (a) Define Data and data sources.

2.1.3.(b) Explain the evolution of data systems.
2.1.4. Various Functional Systems
A hospital information systems (HIS) is a computer system that is designed to manage

all the hospital’s medical and administrative information in order to enable health professional

perform their jobs effectively and efficiently. Figure 1 shows how this process gives decision
makers the ability to determine the things we absolutely have to get right to execute our NOTES
strategy.
Hospital information systems have been an essential part in hospital management and
administration. Early systems consisted of large central computers connected to by dumb
terminals, which are now being replaced by networked microcomputers. The systems
were used to manage patient finance and hospital inventory.
Hospital information systems now focus on the integration of all clinical, financial and
administrative applications and thus could also be called an integrated hospital information
processing systems. The following aspects should be included in the system
• Developing and leveraging accurate metrics that genuinely reflect the unique
character of healthcare resources
• Measuring with precision the value and effectiveness of your system
• Improving succession planning before the retirement boom adversely impacts
knowledge transfer
• Leveraging non-traditional talent pools to identify and cultivate new strategic
points
• Reducing employee turnover and increasing retention by engaging workforce
• Applying process improvement tools such as Lean or Six Sigma to all departments
• Capitalizing on the relationship between organizational goal, employee
performance and patient satisfaction
• Reducing reliance on supplemental staffing agencies by increasing the effectiveness
of recruitment and retention efforts
• Quantifying Individual contribution to a hospital’s bottom-line results
Here are some sample functional requirements for HIS

• OP Registration
• Provide on-line pre-registration functions for gathering patient demographic,
insurance and other data.
• Support short outpatient registration process (e.g. compared to inpatient admissions)
tailored to simpler outpatient service requirements (e.g. blood draws, lab tests).
• Support “recurring” or “series” outpatient accounts that do not require re-entering
registration data at each visit.
• Support automatic transfer of patient data and charges from Electronic Record
and outpatient accounts to inpatient account if patient is admitted.
• Provide quick emergency / trauma department registration process allowing
registration records to be completed later.
1. Patient Accounting
• Support a variety of insurance contract billing requirements such as sending separate
bills to ESI / company and insurance company.

DBA 1757
• Provide comprehensive user-defined front-end coding and billing edit processes
NOTES to validate coding, revenue codes, bill type, etc
• Provide ability to maintain a series (or recurring) outpatient’s master record and
reflect all changes in individual visit records.
• Provide third party log functions to track all payments, charges and adjustments
for inpatients and outpatients.
• Support automatic collection processing that routes accounts to specific followup
steps per user-defined criteria.
2. Medical Records
• Support on-line maintenance and access to medical records for inpatients,
outpatients, and emergency patients.
• Support batch processing of chart locations using report data capture devices
(e.g. portable bar code scanners) used to inventory all charts within a location.
• Provide ability to view and/or print incomplete medical record delinquency reports
by physician showing deficiencies.
• Generate abstracting productivity statistics on amount of work completed and
time spent per chart.
• Provide “quick entry” feature that replaces long medical terminology after short
abbreviation is keyed.
3. Physician Access
• Provide on-line, easy-to-use system for physicians to access patient demographic,
clinical, order, and results information.
• Provide security confidentiality control features to prohibit physician from viewing
and accessing data for other physicians’ patients.
• Provide on-line patient inquiry function showing name and phone of family and
emergency contacts for patients of physician who is logged on.
• Provide electronic signature ID function for physician to electronically record
approval and entry of orders.
• Support on-line graphical display of physician’s patient lab test results for trends,
etc.
4. General Ledge
• Support processing of multiple general ledgers for multi-entity organizations.
• Provide ability to set up and maintain multiple calendars (e.g. use a monthly calendar
for one entity and a quarterly calendar for another).
• Support allocation of revenue and expenses to profit centers by fixed amount and
percentage.
• Show volume units, revenue per unit, and costs per unit on a units-of-service
statistical report.
• Support uploading of data from standard microcomputer file formats to general
ledger system.

5. Budgeting
• Provide integration and sharing of data between general ledger and budgeting
NOTES
systems.
• Compute future period projections based on average of prior years’ data plus or
minus a percentage.
• Support flexible budgeting of revenue, expense, and labour data based on user-
defined volumes.
• Support capital expense budgeting with automatic calculation of depreciation based
on assets useful life.
• Provide option to automatically interface monthly budget adjustments to general
ledger system.
6. Case Mix
• Interface to and capture patient information automatically from the patient care
and financial applications.
• Provide concurrent review functions to monitor utilization during patient stay.
• Maintain and allow on-line access to revenue, cost, and payment history data by
diagnosis group.
• Print financial utilization reports of inpatient and outpatient by financial class.
• Provide ad hoc report writing features within Case Mix system for non-technical
users.
7. Accounts Payable
• Provide ability to compute payment due dates based on the terms of the vendor
discount or user-defined period from the invoice date.
• Maintain employee payment records separately from vendor records for statistical
and reporting purposes.
• Support automated reconciliation of vendor invoices, purchase orders and receipts
to verify quantity ordered, received, accepted and billed before payment is
authorized.
• Print vendor aging report of unpaid invoices for user-specified period (e.g. to see
the outstanding items as of certain date and reconcile the total to the general
ledger).
• Print trend analysis report showing summary of activity for current month, last
twelve months by vendor.
8. Fixed Assets
• Support user-definable asset coding scheme by function, services, structure, cost
center, or operational group.
• Support retroactively transfer of assets including charge of associated depreciation
to appropriate departments or accounts.
• Provide ability to backdate assets additions for the purpose of catching up on
depreciation.

DBA 1757
• Print asset recap showing cost, salvage value, accumulated depreciation, current
NOTES depreciation and book value.
• Interface depreciation journal entries to the general ledger system.
9. Payroll
• Support an unlimited number of earnings codes including (but not limited to) salary,
hourly rate, vacation, sick, holiday, shift differential, overtime, call back, disability,
etc.
• Monitor annual maximum deduction amounts and stop the deduction once the
predefined maximum is reached.
• Automatically adjust garnishment and child support deduction amounts if the
disposable income requirements will not be met after the deduction is taken.
• Process partial period payments to employees who do not work the entire pay
period (e.g. new hires, terminations, on leave without pay, catastrophic leave).
• Provide ability to restart check printing in the event check stock is damaged or
printer malfunctions, with audit controls for damaged check stock.
• Provide ability to synchronize employee master files in payroll system with time
and attendance system.
Figure 2 shows how virtual data access technology that integrates disparate information
from databases, spreadsheets, applications, Web sites and other data sources without
programming, interfaces or changes to existing systems.

As a whole the possible services a hospital information system provides:

NOTES
• Benefit coordination
• Enrollment, eligibility, and entitlement systems
• Outcome research
• Chronic disease management
• Workflow, document, and grants management
• Security and privacy systems and assessments
• Comprehensive data management
With expanding responsibilities and shrinking budgets, government agencies and

organizations face an environment in which their health information systems need to better
share data, create efficiencies of scale, and reduce costs, without sacrificing the privacy
and adherence to other regulatory requirements. Use of technological solutions to meet
these challenges with expertise in security policy, identity management, enrollment, network
management and upgrades, VOIP implementation, database management, data
warehousing, software development (mainframe/mid tier), data center support also serve
the industry for its full usage.
2.4.4.(i). Financial Information System (FIS)
Financial Information Systems are computer systems that manage the business aspect
of a hospital. While healthcare organisation’s primary priority is to save lives, they do
acquire running costs from day to day operations; including purchases and staff payroll.
Healthcare business activities normally are quite complex and the introduction of
Financial Information Systems eases that task’s complexity that hospitals faces.
Some of the common features of Financial Information Systems are:

• Payroll: Handles all the recurring and non-recurring payments and deductions for
employees. All recurring transactions can be automatically generated each payroll
period with non-recurring transactions such as overtime added to the payroll
upon approval. It is also possible to maintain employee pay rates, entitlements,
full salary movements and payroll histories.
• Patient Accounting: This concentrates on financial transactions generated during
a patient’s visit to the hospital. These include inpatient and outpatient charges,
doctor’s fees generated across the hospital, the cost of procedures, operations
and medications.
• Accounts Payable: Handles the processing of invoices and payments within the
hospital.
• Accounts Receivable: This provides support for and the maintenance of the records
of all clients, invoices and payments.

DBA 1757
• General Ledger: This handles the collection, processing and reporting of financial
NOTES data generated by all transactions, enabling a current, accurate and instant view
of the financial status of the hospital at any point in time.
• Fixed Asset Management: This deals with asset data retention and depreciation
forecasting. The transfer of fixed assets between locations, cost centres or
departments; reclassification of assets and reassessments of asset values can
functions that can be done by the Financial Information System.
• Claims Management: Manages all claims that are made to insurance companies
• Contract Management: Keeps track of all ongoing contracts.
Managing patient financial information is complicated by the need to access data

from disparate systems to view all of the activity related to a single patient encounter.
Consolidating this information is further complicated by the fact that electronic data, electronic
documents and scanned documents are rarely tied to the same file. For most organizations,
today’s revenue cycle is characterized by increasing complexity compounded by the sheer
volume of claims to be managed. Information regarding accounts is contained in multiple
disparate systems that may not talk to one another. Electronic information must often be
matched to paper documents stored in a variety of departments. The benefits of implementing
a system will help you to
• Pinpoint problems
• Take timely action
• Improve processes
• Measure individual/departmental effectiveness
• Establish accountability
• Improve revenue recovery
• Shorten the A/R cycle
• Measure staff productivity
2.4.4.(ii) Healthcare Human Resource
With the changing world and constant new technology that is available, managers
need to be aware of the technology that will increase effectiveness in their company. Human
resource information systems (HRIS) have increasingly transformed since it was first
introduced at General Electric in the 1950s. HRIS has gone from a basic process to
convert manual information keeping systems into computerized systems, to the HRIS
systems that are used today. Human resource professionals began to see the possibility of
new applications for the computer. The idea was to integrate many of the different human
resource functions. The result was the third generation of the computerized HRIS, a feature-
rich, broad-based, self-contained HRIS. The third generation took systems far beyond
being mere data repositories and created tools with which human resource professionals
could do much more.

The efficiency of HRIS, the systems are able to produce more effective and faster
outcomes than can be done on paper. Some of the many applications of HRIS are: Clerical NOTES
applications, applicant search expenditures, risk management, training management, training
experiences, financial planning, turnover analysis, succession planning, flexible-benefits
administration, compliance with government regulations, attendance reporting and analysis,
human resource planning, accident reporting and prevention and strategic planning. With
the many different applications of HRIS, it is difficult to understand how the programs
benefit companies without looking at companies that have already benefited from such
programs
Health care organisations need to process a rapidly growing amount of information.

Data entry and information processing workers help ensure the smooth and efficient handling
of information. By keying in text, entering data into a computer, operating a variety of
office machines, and performing other clerical duties, these workers help organizations
keep up with the rapid changes that are characteristic of today’s “Information Age.” Data
entry and information processing workers are known by various other titles, including
word processors, typists, and data entry keyers, and less commonly, electronic data
processors, keypunch technicians, and transcribers.
The information system in hospitals provides the full range of professional level human
resource services to all hospital staff and designated client departments, which include
recruitment and employment, compensation, employee and labor relations, organizational
development and human resource information systems. These functions are performed in
accordance with all applicable laws and regulations and policies, procedures and standards.
Salient Features of the HR information system are

• Maintains complete record of all employees including the Employee Code, name,
Demographic data, Salary in different heads, Department, Designation, PF account,
ESI Account, etc
• Definition of Salary head as per formula or straight away
• Leave’s as per defined by user
• Salary settings as per monthly basis, or on wages basis
• Daily/ Monthly attendance record
• Short Term & Long Term Loans
• Record of employee’s in time, out time, lunch hours, over time
• Application of salary increment formula
• Supports all types of Smart Cards, Bar Cards, etc
2.4.4 .(iii) Material / Purchase and Inventory Management System
As a part of an integrated system or as an individual automation tool, this system may

be incorporated. This deals with the inventory of all, Materials, Consumables, Equipments
& Asset items in different departments of an industry along with their purchase and supplier

DBA 1757
details. Requisitions for different items/equipment are sent to this store from different
NOTES departments and accordingly the Central Store issues items/equipment to various
departments and generate purchase orders for purchases. This also maintains records of
purchases, stock, and supplier list, item/equipment/material master tables.
The Store module ensures that there is a round the clock availability of a sufficient quantity
of raw material and consumables for each department in a mode that neither hinders efficient
clinical work, nor it becomes a threat to the survival of the Store.
Some of the features, the system should possess are as follows

• Maintains the details of all items, its suppliers and purchase details.
• Items can be categorized under different groups.
• Items can be defined for the store i.e. a particular will be able to view only those
items which comes under it.
• Generate Purchase order linked with indents.
• Maintain Separate Stock of Central Store & Multiple Sub Stores.
• A particular store can indent items from all other stores.
• Maintain vendor details from whom Items are being purchased.
• Central Store can acknowledge return of purchased item.
• Various area stores can return items that are not required by them back to the
Central Store.
• Different store can issue Items to other Stores, Department.
• Strict Check on the Expiry Date of Medicines & Consumables.
• Items can be issued according to FIFO & LIFO check
• Maintain Reorder Level of Items and warn accordingly.
• Support on-line entry of purchase order requisitions that can be automatically
converted into purchase orders.
• Edit purchase order data entry for valid vendor number, item, and account codes.
• Support automatic assignment of purchase order numbers.
• Provide on-line inquiry into all purchase orders for a particular item.
• Provide audit trail of changes made to purchase orders.
• Provide interface via modem to vendors’ computers for electronic order entry to
hospital suppliers.
• Support the combining of requisitions from several hospital departments onto one
purchase order.
• Allow tracking of due dates specified by PO or line item.
• Support selection of orders for specific buyers with user-defined criteria (i.e. certain
vendors, type of PO such as stock, non-stock, etc.).
• Allow items to be defined as patient chargeable or department chargeable.
• Support on-line receiving at point of receipt.
• Provide ability to communicate receiving problems to purchasing and/or accounts
payable.
• Print daily receipts report showing items, quantities, vendors, and totals.

• Print receipt exception report of variances from P.O. in item number, quantity, or
units of measure. NOTES
• Provide inventory control functions for stock and non-stock items.
• Maintain current inventory quantities in real time when items are issued, returned,
received or transferred.
• Support on-line inquiry into item status of quantities on hand and on order.
• Support entry of charges and credits for items used (or not used) by patients.
• Calculate inventory item cost using the average cost method.
• Allow departments to order supplies on-line and print requisitions at inventory
locations.
• Print stock usage report of past 12 months showing quantities and Re volume by
item and department.
• Track and report trends for item usage.
• Track item shelf life based on purchase or expiration date and print item
obsolescence report.
• Support maintenance of a purchase contract data base.
• Automatically alert purchasing of a price protected item. (e.g. message on screen
and/or prompt the operator doing a price change).
• Calculate patient charge price using hospital standard markup policy and actual
purchase price.
• Produce bar code labels for patient charge items.
• Record patient charges using a bar code reader.
• Interface to the hospital information system to retrieve patient information Provide
activity statistics including number of lines purchased by buyer.
• Provide activity statistics including number of lines received.
• Provide complete turnkey on-site implementation and project management support.
• Provide on-site training to users.
• Provide access to system maintained data element definitions within report writer
software.
• Provide ability to down load data into popular PC spreadsheet, database and
word processing file formats.
• Support interface to bar code readers.
• Provide ability for system administrator (or other authorized user) to modify screen
layouts and flow with minimal programming effort.
• Supply all computer program source code on media (e.g. tape, CD) to user.
• Provide future software releases and updates to all applications as part of regular
software maintenance fees.
Also some key Reports which help in decision making are

• Report of all items according to their group
• Stock in Hand Report (Group & Batch Wise)
• Stock Valuation on Purchase Rate & M.R.P.

DBA 1757
• Report on Stock Movement as when & from where Item was issued and to whom
NOTES it was issued.
• Items Expiry list & warning
• Reorder Level of Items.
• Purchase & Issue Registers.
2.4.4 .(iv) Laboratory Information Management System
Patient care has become increasingly complex with the widespread use of advanced
technologies in routine care. Healthcare providers must keep track of a staggering amount
of information — and their failure to do so can have a detrimental effect on patient care.
Clinical Information System (CIS) is a solution to this dilemma. CIS is designed to bring
the management of patient data into the information age. It is intended to replace the
Medical Records Department of a medical institution, supporting the acquisition, storage,
manipulation, and distribution of clinical information throughout the organization.
This can be designed for a wide variety of laboratory environments operating in many
scientific and industrial disciplines, disparate business processes into a single, compliant
platform with comprehensive reporting, surveillance and networking capabilities. The result
is vastly enhanced data management and sharing-within the laboratory and across the
enterprise.
Some common sample features are

• Store diagnoses codes in registration function.
• Support retrieval of patient records by partial (e.g. first few letters of) patient last
name.
• Support interface to order communications system of HIS to automatically receive
order data.
• Include test, profile, or battery name (mnemonic code) in order data.
• Process orders for profiles that include multiple tests (e.g. cardiac enzyme profile).
• Allow a miscellaneous test code so previously undefined tests can be ordered
and charged.
• Ability to correct a field on a screen without having to re-enter entire order
transaction.
• Allow entry of orders for future dates.
• Allow splitting one ordered test into more than one request (e.g. group tests, pre-
op, coag screen).
• Allow review and verification of held orders on-line by technologist.
• Automatically check for and warn of duplicate single test orders with profile
orders.
• Support cancellation of tests—logging accession #, test code, patient name,
reason, date, time, and tech ID.
• Provide simple method to order additional test requests on sample already received
and processed in lab.

• Allow cancellation of an order without canceling results.

• Provide access to price information within order entry function. NOTES
• Provide option to assign assession numbers at time of specimen receipt.
• Print specimen collection labels for timed and routine collections.
• Provide multiple labels per test ability to print.
• Print tube type and volume on specimen labels.
• Print instructions/comments (e.g. do not collect from right arm) on specimen labels.
• Print phlebotomist activity summary showing first & last draw times, locations, #
patients drawn, and # misses.
• Allow patient test to be incomplete for at least 8 weeks in the system.
• Flag routine orders when timed pick-up or stats etc. are ordered, to prevent
multiple sticks.
• Print aliquot labels when more than one test is drawn in the same collection tube.
• Ability to remove unsuitable or lost specimens from work list, flag in system, and
activate recollection.
• Provide that uncollected specimens continue to appear on subsequent lists until
cancelled or collected.
• Support a way to identify the phlebotomist, (doctor, nurse, etc.) in system for
specimens not drawn by laboratory personnel.
• Track worklists by unique control number for on-line inquiry, reporting, and audit
purposes.
• Allow user to easily define worklist formats for different work stations without
programming.
• Print worklists by workstation.
• Print ordering physician on worklist.
• Print the lot number of the reagent in use for the specific test on the worklist.
• Flag uncollected specimens on worklist.
• Allow lab technologist to update worklist on-line for STAT tests.
• Provide on-line inquiry into work list by test type.
• Print daily detailed master log of all work performed in lab for audit purposes.
• Include data for tracing order (dates, times, tech ID, results) from order entry to
final reporting in master log.
• Provide index to master log by accession number.
• Assign quality control specimens to a worklist on a rotating basis, in a predefined
sequence, specific to each worklist.
• Support ability to edit, insert, and delete items on worklists to meet immediate
needs.
• Support capture and processing of result data from automated analyzers via
computerized (e.g. RS-232) interface.
• Automatically record start, stop, and elapsed time of automated analyzer tests.
• Display patient age and sex in results entry screen.
• Provide capabilities for graphic display of test results.
• Support entry of comments for non-numeric results and interpretative reporting
in results entry screens.

DBA 1757
• Maintain edit table of lab-defined panic, delta, and reference result ranges based
NOTES on age and sex.
• Display previous test’s value, time, and date if delta check limit is exceeded during
result entry.
• Print list of received but untested specimens due to insufficient quantity.
• Print list of all patient tests that require scrutiny (e.g exceed delta check, panic
values, reference intervals).
• Track activity for special procedures related to surgical pathology.
• Provide physician utilization report (e.g. number of tests requested by a physician).
• Generate outpatient statistics based on financial class.
• Calculate employee productivity by shift, by month, by year, and to date.
• Allow stats to be weighted more than routine procedures.
• Ability to generate patient lists (with certain demographic data) who meet specific
result criteria for public health reporting.
• Maintain calibration records for on-line instruments.
• Allow for instrument status (recent service, troubleshooting, etc.) to be stored
on-line.
• Generate revenue reports by test.
• Count slides as one-half for certain types of specimens for calculation of slides
screened by a Cytotechnologist.
• Provide ability for user to determine and change the workload for a
Cytotechnologist at any time.
• Report the technical supervisor’s re-examination of 10% of each Cytotechnologist’s
case workload.
• Compare the annual statistical evaluation for each Cytotechnologist against the
laboratory for the number of gynecologic cases where cytology and histology are
discrepant.
• Report daily cytology smear quality review.
• Support automatic interface to HIS for transmitting patient lab charge data.
• Provide group billing for non-hospital clients (e.g. physician’s office, clinics).
• Support multi-tiered price structure by service type (e.g. IP, OP, contract,
referred).
• Support price structure that accommodates higher prices for tests with multiple
codes.
• Support entry of reason for discarded, outdated, and quarantined units.
• Support entry and tracking of lot number of reagent used for a particular patient.
• Alert the user to the entry of an ABO & Rh type that disagrees with previous
results.
• Provide report of units outdated, returned to supplier, and % units cross-matched
but not transfused, by diagnosis & surg. procedure.
• Provide comment field in blood unit inventory record.
• Allow manual entry of date/time of issue of unit if system was down.
• Ability to track blood products e.g. packed cells, whole blood, FFP, Cryo,
Platelets, etc.
• Display antibodies with patient demographics.

• Log all transactions by date, by time, by technologist.

• Allow simultaneous multiple crossmatches on multiple patients. NOTES
• Provide monthly report of crossmatch to transfusion ratio.
• Ability to identify autologous / designated donations or a special antigen type.
• Ability to override the system if an incompatible unit needs to be transfused.
• Warn user if retyping results entered do not match the blood type entered.
• Ability to assign a pooled number for 2 to 10 units combined for a single
transfusion.
• Alert personnel if an outdated unit is chosen from inventory.
• Provide on-line help screens to assist novice users in all applications.
• Provide multi-level password security down to options within menus.
• Utilize code tables for processing control and other system parameters that can
be maintained by system administrator.
• Provide user-friendly report generator software with graphical user interface.
• Provide access to system maintained data element definitions within report writer
software.
• Maintain and allow on-line access to a system-wide data dictionary.
• Provide data management design that supports integration and sharing of data
among all applications.
• Provide data management features that eliminate the redundant maintenance of
duplicate data (e.g. relational database, etc.).
• Provide sufficient back-up and recovery features to assure minimal data loss due
to a system failure, power outage, etc.
• Provide sufficient back-up and recovery features to assure minimal data loss due
to a system failure, power outage, etc.
• Provide technical documentation for support staff including system overviews,
design, flowcharts, and file layouts.
• Provide ability for system administrator (or other authorized user) to modify screen
layouts and flow with minimal programming effort.
• Provide future software releases and updates to all applications as part of regular
software maintenance fees.
• Provided toll free customer support 24 hours, seven days per week.
• Provide commitment to support healthcare industry system integration standards
QUESTIONS:
2. 4..a. Mention various functional information systems.
2.4.b. Explain financial Information system in an Hospital.
2.4.c. Explain Purchase and Inventory Management system.
2.4.d. Narrate Laboratory Management information system.
SUMMARY
You have learned the data sources in detail. Also you have understood the various
functional systems in hospital manage.

DBA 1757
EXERCISES
NOTES
1. Identify the various data sources for a nearby hospital to maintain information
about Healthcare.
2. Meet the financial Officer in a nearby hospital and collect information about Financial
Operation System of the Hospital.
3. Get a model of A Human Resources Information system implemented in a nearby
hospital.
4. Collect the necessary information required to design and develop the Purchase
and Inventory information system of a Hospital .

NOTES
CHAPTER 2
2.2 ELECTRONIC MEDIAL RECORD
2.2.1.Introduction
The sharing of clinical information increases the accessibility of important health

information, can reduce costs through elimination of duplicate tests and prescriptions, and
most importantly, improves the quality of care. The availability of such information in
emergency situations can literally save lives. The sharing of clinical information increases
the accessibility of important health information, can reduce costs through elimination of
duplicate tests and prescriptions, and most importantly, improves the quality of care. The
availability of such information in emergency situations can literally save lives.
“EHR is a digital collection of a patient’s medical history and could include items like
diagnosed medical conditions, prescribed medications, vital signs, immunizations, lab results
and personal characteristics like age and weight.”
2.2.2. Learning Objectives
After reading this chapter, you will understand

• What is a Electronic health Record.
• Worldwide standard for HER
• Points to remember while purchasing a HER
• Benefits of HER
• The Processess of EHR
2.2.3. Description
The Electronic Health / Medical Record (EHR / EMR) is a longitudinal electronic

record of patient health information generated by one or more encounters in any care
delivery setting. Included in this information are patient demographics, progress notes,
problems, medications, vital signs, past medical history, immunizations, laboratory data
and radiology reports. The EMR automates and streamlines the clinician’s workflow. The
EMR has the ability to generate a complete record of a clinical patient encounter - as
well as supporting other care-related activities directly or indirectly via interface - including
evidence-based decision support, quality management, and outcomes reporting.
In this section you will find many resources that contribute to the ability for healthcare
organizations to realize a longitudinal electronic record that spans across the continuum of
healthcare. Topics of interest include a focus on quality, efficiency, effectiveness and the
safety of patient care through a variety of tools and resources in different formats. By

DBA 1757
providing this information, Leadership can be focused on collaboratively working together

NOTES to achieve the goal of EMRs in use in 80 percent of healthcare organizations and 50
percent of physician practices by 2010.
Any such product must meet the following requirements:
1. Clinician access to the EHR / EMR must be based upon a proven application used
in demanding healthcare environments – and not just a “viewer” or “portal” written
specifically for this purpose.
2. The database structure of the patient record must be based upon a proven product
with an information model that has been clinically proven in a wide variety of
hospitals, clinics, and community settings – preferably in multiple countries – to
ensure that it supports the complex needs of diverse organizations and is capable
of supporting additional needs as requirements inevitably grow.
3. A powerful integration platform is required for rapid integration of clinical and
demographic information from a variety of sources, with a universal standard.
Since it is not practical to assume that existing systems support (or will support in
a reasonable time) a common format, the ability to rapidly develop support for
other formats is critical.
4. The core database and integration technologies must support rapid development,
rapid customization, and massive scalability.
5. A strong standards-based approach is required.

A few world wide standards for EHR / EMR are listed below

Healthcare data exchange standards supported

NOTES
2.2.3.(i) Questions you should ask when purchasing an EMR system:
1. What basic features does your practice need?
2. How do you receive your lab results?
3. Who in the office will assist with the implementation?
4. How can this software help the workflow of your office?
5. Will you enter old data into the system?
6. How much time will you need for training?
7. What type of software support do you require? Remote, onsite or both?
8. How do you currently submit your electronic claims?
9. What goals do you expect to achieve?
10.How do you remind patients of their appointments?
11. What is your budget?
12. How are you writing prescriptions?
2.2.3.(ii). How can EMR benefit you ?
Improved accuracy
Because you are using software rather than hand-writing notes and charting, your
practice will immediately benefit from improved legibility, easier appointment scheduling
and more accurate insurance billing. Improvements in coding quality and reduced claim-
denial rates, accuracy in record keeping and streamlined flows and processes in your
practice are an additional benefit. All of which leads to an improved cash flow.
Increased efficiency
You naturally capture more patient information and facilitate communications among
your staff. If implemented correctly, this can lead to more streamlined office processes and
better allocation of employee resources. It doesn’t take as long to get information into a
patient’s chart because practioner’s tend to enter data immediately after or during the
patient visit. Nurses also report they spend much less time looking for patient information.
Lost charts and illegible records are a thing of the past.
For many practices, documentation on patient visits is incorporated into the chart
much sooner. Other practices report that by implementing direct lab interfaces, they’ve
reduced data entry and filing time. There is also a reduced wait time between patient visits
and posted lab results, resulting in faster patient notification and increased patient satisfaction.

DBA 1757
Better patient safety

NOTES
Lost charts are eliminated, plus nurses and administrators have instant access to patient
charts, allowing them to answer questions quickly and efficiently. Having instant access to
charts also makes it easier to provide important patient education material.
When there are drug recalls and time is of the essence, a system allows physicians to
quickly locate at-risk patients and notify them of any actions they need to take. Another
important safety feature of EMR software is that clinicians easily have access to a patient’s
ongoing healthcare requirements each time a patient’s chart is displayed. Many practices
have used this information to update patient’s tetanus and other immunizations right away,
which ultimately leads to healthier and happier patients.
Because patient prescription information is entered, it is much easier to identify drug
interactions, dosage information, patient instructions, formularies and more.
More accurate coding
Accurate coding can save your practice both time and money in several ways. The
number of rejections by insurance companies is drastically reduced, which in turn improves
your accounts receivables. EMR software can also advise physicians of appropriate E&M
coding, which can reduce the tendency to under-code just to be safe. Many EMR users
also find they bill for more services per patient visit because of more appropriate and
improved coding.
Because coding can be done during or right after the patient visit, physicians tend to
more accurately record the type of services delivered — and to record all the services
delivered.
Improved patient confidentiality
EMR software offers the reporting capabilities and documentation requirements to

meet HIPAA requirements and any quality initiatives a practice implements. With EMR
software, it is also much easier to allow different levels of access to different employees in
the practice. Lost charts and misfiled records quickly become a thing of the past.
Better resource allocation
Many practices begin to re-evaluate their business processes when they implement
EMR software. The patient’s entire experience is often improved, both in and out of the
exam room. Practices can improve the way they schedule patient visits, make referrals and
handle episodic illnesses. A physician on call, for example, may speak with a patient,
schedule an appointment with a colleague, send referral information and schedule a reminder
for follow-up appointments, all before hanging up. This type of convenience and flexibility
gives physician practices a strategic advantage over others while greatly improving their
patient’s experience.

Other practices have found that they need much less administrative staffing and can
reallocate those expenditures into hiring additional nurses or other clinicians. This allows NOTES
the patients themselves to have a better experience and spend more time with a service
provider. It also allows your practice to see more patients in a timely manner, thus increasing
revenues.
Significant cost savings
There are several variables that lead to a positive return on investment with regard to
EMR software. To most accurately measure cost savings, practitioners should first determine
what their expenditures are before implementation. Evaluate costs for supplies, storage
space, time spent filing and time spent looking for lost charts, to name a few. By itself, the
costs of maintaining storage space for charts can be significant.
Many practices have found they have eliminated transcription costs entirely. Related
miscellaneous expenses that can also be eliminated include courier fees and copying. Other
expenses, which may be less obvious but are equally important, include the potential to
increase revenues as a result of more accurate coding, improved clinical productivity and
more complete documentation. Medicare and other insurance requests may more accurately
represent the level of care provided because documentation is done at the time of service
or shortly thereafter.
Reduced malpractice
Many malpractice insurance carriers now offer premium discounts for using an EMR
as a result of the improved documentation, reminders and alerts provided.
2.2.3.(iii). The processes of EHR / EMR
Record Digitization
Your old paper documents can be converted into digital files, and seamlessly integrated
into the system environment. As a result, they become more accessible, more portable,
more reliable, and more secure, and can be stored, managed, and protected more efficiently
and cost-effectively, without compromising the integrity and security of your most critical
records.
Research Integration
This is to revolutionize research and information retrieval, by actively researching

resources and connecting relevant information with your documents. Click of a button and
your own documents are transformed to a gateway for standards for the entire hospital or
group of hospitals or any other reference links if necessary.

DBA 1757
Dynamic Collaboration
NOTES
It contains unparalleled collaboration capabilities that enable you to quickly and easily
share your patients’ electronic medical records with any medical provider or insurance
agency, anywhere around the globe. Other medical providers will be able to receive patient
records in seconds, in the same format viewed by you.
Individual & Interactive Dashboards
While medical providers are able to electronically sign off on or finalize their patient’s
records, group or office administrators can manage providers and their staff, patient records,
billing, and other important functions. Additionally, medical providers’ assistants can access
the system using their own dashboard, which is similar to that of the medical provider they
are assigned to, with minor restrictions.
Dynamic Tracking
In an effort to eliminate ambiguities and errors, capture end-user login and log-off
times and IP addresses, time-stamp all uploaded files, create an audit trail for all document
revisions, and more.
Communication Integration
Advanced communication features for greater and more effective interaction between
all user groups, it also offers the ability to effortlessly email, print, or fax documents directly
from the system, eliminating the need to download and print hard copies, then manually
send or distribute them. This not only saves paper and ink, but will free up the valuable
time of your support personnel who are assigned to the routine administration of such
tasks.
Few other tasks may as listed below

• Comprehensive patient information including demographics, insurance,
appointments, contacts, referrals, notes, case management details, and more
• Fast patient registration with alert messages including duplication warnings
• Case specific records: insurance plans, hospital stays and other claims
• Patient and guarantor account retrieval by numerous search criteria including
patient and/or guarantor name, date of birth, phone number, insurance policy
number, account number, transaction number, medical record number, claim
number, and other user definable fields
• Procedure and diagnosis code tracking for immunizations, mammography,
periodic check up, etc.
• Patient and insurance company balances displayed in every patient-related
view
• Built-in word processing, seamlessly integrated with other system modules
• Mail-merge, label printing for automation of single letters or letters to groups

of patients, providers, insurance companies, etc.

• Letter creation based on: date of service range, diagnoses, procedures, birthday NOTES
letters, operative reports, dunning and pre-collection letters, request for insurance
information, patient labels, referring physician labels
• Free-form letters and documents supported, both stand-alone or generated
by merging information from the system databaseRobust set of system reports
generated may as follows:
Transaction listing
• Aged trial balance (user-defined patient / insurance aging categories)
• Recall report (selected by patient name, account number, birth date, provider,
recall reason, last service date, or procedure selection)
Demographics reports
• Numerous views and reports available including schedule printouts by provider/
room, daily/weekly schedule report, monthly density report, and reports for no-
shows, cancellations, and reschedules
Search by day, time, place, provider and appointment type
• New patient listing sorted/filtered by any combination department, insurance,
place-of-service, provider, referring doctor, plus date range (daily, weekly,
monthly, quarterly, annually, and for any date or date range)
• Screen-preview and printing of all reports, statements, receipts, immunization
record, insurance forms, encounter forms, and letters.
Detailed insurance plan information screen
• On-screen insurance claim status (insurance claims pre-submission report,
insurance unpaid claims report, automatic claims re-submission, and claims
tracking)
• Automatic claims resubmission: user definable by insurance carrier
• Procedure-diagnosis code linkage: helps ensure claim acceptance by
automatically verifying that an accurate and appropriate diagnosis code is attached
• Automatic cascading: sequential billing of an unlimited number of carriers per
patient
• Appointment Schedule
• Automatic recall reminders for recurring procedures
• Separate office and surgical schedules
• Simultaneous display of up to six different dates, providers, rooms
• Charge slip and label printing for chart preparation
• Administrator-defined access permissions and customizations
• Multiple security levels: read-only, add, modify, delete; access assigned
per user, per group, per module
And other user-defined reports include

• Practice analysis report
• Procedure analysis report
• Referral analysis report
• Insurance aging report
• Diagnosis analysis report

DBA 1757
• Transaction summary report
NOTES • Deleted transaction report
• Practice Summary Report
• Integrated Document and Image Scanning
QUESTIONS
2.2.3.a. What is an electronic Medical Record?
2.2.3.b.What are the parameters to be considered while purchasing an EMR?
2.2.3.c. Mention the benefits of EMR.
2.2.3.d. Explain the processes of EMR.
SUMMARY
You have learned what is a Electronic Medical record and its importance.
EXERCISE
1. Identify the fields of an Electronic Medical Record.
2. Draw the Electronic structure of a medical record with the help of the relevanting
formation Collected from nearby hospital.

NOTES
UNIT III
DATABASE MANAGEMENT
CHAPTER 1
3.1 DATABASE MANAGEMENT
3.1.1. Introduction
A database management system (DBMS), or simply a database system (DBS), consists

of a collection of interrelated and persistent data, (usually referred to as the database
(DB)) set of application programs used to access, update and manage that data (which
form the data management system (MS)).
The goal of a DBMS is to provide an environment that is both convenient and efficient
to use in retrieving information from the database, storing information into the database.
Databases are usually designed to manage large volume of information. This involves definition
of structures for information storage (data modeling), provision of mechanisms for the
manipulation of information (file and systems structure, query processing), providing for
the safety of information in the database (crash recovery and security) and concurrency
control if the system is shared by users.
Commonly available DBMS are listed below.

• IBM
• DB2/MVS
• DB2/UDB
• DB2/400
• Informix Dynamic Server (IDS)
• Microsoft
• Access
• SQL Server
• Desktop Edition (MSDE)
• Open Source
• MySQL
• PostgreSQL

DBA 1757
• Oracle
NOTES • Oracle DBMS
• RDB
• Sybase
• Adaptive Server Enterprise (ASE)
• Adaptive Server Anywhere (ASA)
• Watcom
After the completion of this chapter, you should be able to

• Understand the importance of health data and data base management concepts
• Learn Abstraction , instances and schemas
• Understand the Data languages
• Know the data models in practice
3.1.3 Data Base Management Concepts

The data represented in table form in computer system is called Database.
The activity of entering, deleting, updating , retrieving and processing of data in a table is
called database management system.
Definition
A collection of programs that enables you to store, modify, and extract information
from a database. There are many different types of DBMSs, ranging from small systems
that run on personal computers to huge systems that run on mainframes. The following
are examples of database applications:
• computerized library systems
• automated teller machines
• flight reservation systems
• computerized parts inventory systems
The information from a database can be presented in a variety of formats. Most

DBMSs include a report writer program that enables you to output data in the form of
a report. Many DBMSs also include a graphics component that enables you to output
information in the form of graphs and charts.
3.1.3.(i). Health data
Acquisition and processing of the data for the health library is an ongoing task,
continuously updating existing collections with the most recent available data as well as
ongoing development of new collections for adding to the library every year.

The Quality assurance of the data in use is another major component of the data work.
Processes for validation, establishing comprehensive metadata, classifications and data NOTES
dictionaries, all undergo continuous development through close consultation with data users,
stakeholders, other major health data publication agencies and in accordance with agreed
health information standards.
Confidentiality of the data is an important issue, and methods include a combination

of suppression, selection of data elements and appropriate levels of aggregation, which
can assure confidentiality while still providing high quality detailed aggregated data.
Ideally, a universal electronic health record (EHR) will be a seamless patient record
that crosses the continuum of care. “An electronic health record is a digital collection of a
patient’s medical history and could include items like diagnosed medical conditions,
prescribed medications, vital signs, immunizations, lab results, and personnel characteristics
like age and weight.”
Following are some of the functions of EHRs
• Order entry/order management : Clinical test, consultations, and medication

order entry which are managed electronically.
• Results management : Physicians are able to access all information on patient
care delivered at the hospital or health system.
• Electronic health information/ data capture : All patient health records are
contained in a computerized repository.
• Administrative processes : Scheduling, resource management, billing, and other
administrative systems are interoperable.
• Electronic connectivity : There is fully effective electronic exchange of clinical
data among the healthcare team and other care partners.
• Clinical decision support : Enhanced clinical performance is achieved through
computerized tools (e.g., computer-assisted diagnosis and disease management.)
• Health outcomes reporting : The system can automatically extract information
for quality indicator reporting.
• Patient access : Patients have remote access to their individual records.

DBA 1757
The figure below (figure 3.1) represents a database system and its constituents
NOTES
Figure 3.1. Database system structure
3.1.3.(ii). Database Approach
(A) History of Database Systems
In 1950s and early 1960s data processing were done using magnetic tapes for storage
providing only sequential access, punched cards for input.
In late 1960s and 1970s, High-performance transaction processing were in progress,

in which hard disks allow direct access to data, network and hierarchical data models in
widespread use, Ted Codd defines the relational data model.
In 1980s, research relational prototypes evolve into commercial systems, SQL became
industrial standard, Parallel and distributed database systems, Object-oriented database
systems came into existence.
In 1990s, large decision support and data-mining applications were carried out. Large
multi-terabyte data warehouses and Web commerce emerged.
In 2000s, XML and XQuery standards and automated database administration started
emerging.

(B) Need for Database Systems

NOTES
In the early days, database applications were built directly on top of file systems.
Because of the drawbacks of using file systems to store data, data redundancy and
inconsistency, multiple file formats, duplication of information in different files, difficulty in
accessing data, need to write a new program to carry out each new task, data isolation —
multiple files and formats, data integrity problems and constraints a database system
approach came into existence.
(C) Data Components
In continuation of some of the methods used to organize data beginning with data
collections through to individual data types listed below
Data Collections: a series of data collections (examples: ‘Hospital Separations’, ‘Deaths’,

‘Medicare’, and ‘Population’).
Datasets: All data collections consist of a series of datasets, each one dealing with a
particular theme in the contents of the collection (examples: ‘Demography’, ‘Diagnosis’,
‘Procedure’, and ‘Detailed Cause of Death’). This is the level below which you can begin
choosing data for your table.
Data Variables: Within each dataset is a set of data variables (Examples: ‘Age’, ‘Sex’,
‘Birthplace’, ‘Income’, ‘Diagnosis’ etc.) which can be selected as rows or columns of a
table, or used to reduce the scope of the table (for example, using ‘Age’ to subset the table
scope to ‘persons under 40 years of age’).
Data Items: Most datasets contain several data items to be used as table contents. Data
items are descriptions of the types of data that is presented in the table cells (examples:
numbers, deaths, persons). ‘Hospital Separation’ datasets usually contain ‘Average duration
of Stay’ and ‘Number of Bed Days’ as well as ‘Numbers of Separations’. Some data
collections contain many data items; the Medicare collections allow tabling of different
data items, mostly dealing with financial issues. Data items must be selected in conjunction
with a data calculation.
Data Calculations
If data items are descriptions of data types (separations, currency, persons etc.) then
the data calculations are the expressions of those data items in a table (examples: ‘Numbers’,
‘Row percentages’ and ‘Column percentages’). All datasets contain these three data
calculations, but many datasets contain a large range of additional calculation types.
Data Confidentiality
Each dataset is carefully worked up to contain a judicious combination of data variables

which will not infringe acceptable standards of commercial and individual confidentiality.

DBA 1757
Certain small application areas cannot be included in the output data because their population
NOTES size is too small; these areas are combined with neighbouring areas to form a more suitable
area for statistical output.
For many data variables, the finest level of detail cannot be released.
3.1.3.(iii) Levels of Abstraction, Instances and schemas
To approach a data system, certain levels were defined based on the data availability,
layout and structure. The following levels can be defined. terming the following levels.
• Physical level : describes how a record (e.g., customer) is stored.
• Logical level : describes data stored in database, and the relationships among
the data.
typecustomer= record
customer_id: string;
customer_name: string;
customer_street: string;
customer_city: integer;
end
• View level : A way to hide: (a) details of data types and (b) information (such as
an employee’s salary) for security purposes.
Instances and Schemas
Similar to types and variables in programming languages, there are instances and
schemas as explained below
Schema is the logical structure of the database e.g. The database consists of information
about a set of customers and accounts and the relationship between them. It is analogous
to type information of a variable in a program. Schema are classified into physical and
logical schema. Physical schema is the database design at the physical level. Logical
schema is the database design at the logical level.
Instance is the actual content of the database at a particular point in time. It is analogous
to the value of a variable
The Physical Data Independence is the ability to modify the physical schema without
changing the logical schema. The applications depend on the logical schema, In general,
the interfaces between the various levels and components should be well defined so that
changes in some parts do not seriously influence others.

3.1.3.(iv). Data languages

NOTES
The languages used to interact in a database level vary from the nature of language
usage with respect to data such as
(I ) Data Manipulation Language (DML)
It is a Language for accessing and manipulating the data organized by the appropriate
data model
• DML also known as query language
• Two classes of languages
• Procedural – user specifies what data is required and how to get those data
• Declarative (nonprocedural) – user specifies what data is required without
specifying how to get those data
• SQL is the most widely used query language
(II) Data Definition Language (DDL)
It is a specification notation for defining the database schema.
Syntax
Create Table TableName(Field Name Data type(Data length), Field Name Data
type(Data length) );
Example
Create Table account(acc_number char(10), balance integer(20));
The DDL compiler generates a set of tables stored in a data dictionary which contains
data dictionary comprising of metadata (i.e., data about data)
• Database schema
• Integrity constraints
• Domain constraints
• Referential integrity (references constraint in SQL)
• Assertions
• Authorization
The Data storage and definition language specifies the storage structure and access
methods used.
(III) Data Control Language (DCL)
Data Control Language is used to manage user access to an Oracle database

DBA 1757
DCL Statements are

NOTES
COMMIT
ROLLBACK
SAVEPOINT
GRANT
REVOKE
QUESTIONS:
3.1.3. (a).Define Health data.

3.1. 3. (b).Explain the need for a Database system.
3.1. 3. (c).What are Data components
3.1. 3. (d).Define Abstraction,Instances and Schemas.
3.1. 3. (e).Explain DML,DDL and DCL.
3.1.4. Data Models

• Data modeling is a collection of tools for describing
• Data
• Data relationships
• Data semantics
• Data constraints
It is the act of exploring data-oriented structures. Like other modeling, data models
can be used for a variety of purposes, from high-level conceptual models to physical data
models. From the point of view of an object-oriented developer data modeling is
conceptually similar to class modeling. With data modeling you identify entity types whereas
with class modeling you identify classes. Data attributes are assigned to entity types just as
you would assign attributes and operations to classes. There are associations between
entities, similar to the associations between classes – relationships, inheritance, composition,
and aggregation are all applicable concepts in data modeling. Data analysis is a term that
has become synonymous with data modeling. Although in truth, the activity seems to have
more in common with synthesis than analysis.
Notable data modeling techniques include IDEF, entity-relationship diagrams,

Bachman diagrams, Barker’s notation, Object Role Modeling (or Nijssen’s Information
Analysis Method),the business rules approach, object-relationship modeling, and RM/T.
Common data modeling tools include GNU Ferret, Datanamic DeZign, ERwin, ARIS,
Oracle Designer, Visio Microsoft, SILVERRUN, Mogwai ER-Designer, MySQL
Workbench, PowerDesigner, and ER/Studio.

3. 1.4.(i) Data Models Used in Practice’

NOTES
To understand better we need to discuss how data models can be used in practice.
You are likely to see three basic styles of data model:
• Conceptual data models. These models, sometimes called domain models, are
typically used to explore domain concepts with users. High-level conceptual models
are often created as part of your initial requirements envisioning efforts as
they are used to explore the high-level static business structures and concepts.
On traditional teams conceptual data models are often created as the precursor to
LDMs or as alternatives to LDMs.
• Logical data models (LDMs). LDMs are used to explore the domain concepts,
and their relationships, of your problem domain. This could be done for the scope
of a single project or for your entire enterprise. LDMs depict the logical entity
types, typically referred to simply as entity types, the data attributes describing
those entities, and the relationships between the entities.
• Physical data models (PDMs). PDMs are used to design the internal schema
of a database, depicting the data tables, the data columns of those tables, and the
relationships between the tables.
Figure 1 presents a simple LDM and Figure 2 a simple PDM, both modeling the concept
of customers and addresses as well as the relationship between them. Notice how the
PDM shows greater detail, including an associative table required to implement the
association as well as the keys needed to maintain the relationships. PDMs should also
reflect your organization’s database naming standards, in this case an abbreviation of the
entity name is appended to each column name and an abbreviation for “Number” was
consistently introduced. A PDM should also indicate the data types for the columns, such
as integer and char(5). Although Figure 2 does not show them, lookup tables (also called
reference tables or description tables) for how the address is used as well as for states and
countries are implied by the attributes ADDR_USAGE_CODE, STATE_CODE, and
COUNTRY_CODE.
Figure 1. A simple logical data model.

DBA 1757
NOTES
Figure 2. A simple physical data model.
For example: between Customer and Address there really should be two names
“Each CUSTOMER may be located in one or more ADDRESSES” and “Each ADDRESS
may be the site of one or more CUSTOMERS”.
Data models can be used effectively at both the enterprise level and on projects.
Enterprise architects will often create one or more high-level LDMs that depict the data
structures that support your enterprise, models typically referred to as enterprise data
models or enterprise information models. An enterprise data model is one of several views
that your organization’s enterprise architects may choose to maintain and support – other
views may explore your network/hardware infrastructure, your organization structure, your
software infrastructure, and your business processes (to name a few). Enterprise data
models provide information that a project team can use both as a set of constraints as well
as important insights into the structure of their system.
3. 1.4.(ii).Hierarchical Model
The hierarchical data model organizes data in a tree structure. There is a hierarchy of
parent and child data segments. This structure implies that a record can have repeating
information, generally in the child data segments. Data is a series of records, which have a
set of field values attached to it. It collects all the instances of a specific record together as
a record type. These record types are the equivalent of tables in the relational model, and
with the individual records being the equivalent of rows. To create links between these
record types, the hierarchical model uses Parent Child Relationships. These are a 1:N
mapping between record types. This is done by using trees, like set theory used in the
relational model, “borrowed” from maths. For example, an organization might store
information about an employee, such as name, employee number, department, salary. The
organization might also store information about an employee’s children, such as name and
date of birth. The employee and children data forms a hierarchy, where the employee data
represents the parent segment and the children data represents the child segment. If an
employee has three children, then there would be three child segments associated with one
employee segment. In a hierarchical database the parent-child relationship is one to many.
This restricts a child segment to having only one parent segment. Hierarchical DBMSs
were popular from the late 1960s, with the introduction of IBM’s Information Management
System (IMS) DBMS, through the 1970s.

3. 1.4.(iii)Network Model
NOTES
The popularity of the network data model coincided with the popularity of the
hierarchical data model. Some data were more naturally modeled with more than one
parent per child. So, the network model permitted the modeling of many-to-many
relationships in data. In 1971, the Conference on Data Systems Languages (CODASYL)
formally defined the network model. The basic data modeling construct in the network
model is the set construct. A set consists of an owner record type, a set name, and a
member record type. A member record type can have that role in more than one set, hence
the multiparent concept is supported. An owner record type can also be a member or
owner in another set. The data model is a simple network, and link and intersection record
types (called junction records by IDMS) may exist, as well as sets between them . Thus,
the complete network of relationships is represented by several pairwise sets; in each set
some (one) record type is owner (at the tail of the network arrow) and one or more record
types are members (at the head of the relationship arrow). Usually, a set defines a 1:M
relationship, although 1:1 is permitted. The CODASYL network model is based on
mathematical set theory.
3. 1.4.(iv). Relational Model
(RDBMS - Relational Database Management System) A database based on the

relational model developed by E.F. Codd. A relational database allows the definition of
data structures, storage and retrieval operations and integrity constraints. In such a database,
the data and relations between them are organised in tables. A table is a collection of
records and each record in a table contains the same fields.
Properties of Relational Tables:

• Values Are Atomic
• Each Row is Unique
• Column Values Are of the Same Kind
• The Sequence of Columns is Insignificant
• The Sequence of Rows is Insignificant
• Each Column Has a Unique Name
Certain fields may be designated as keys, which means that searches for specific
values of that field will use indexing to speed them up. Where fields in two different tables
take values from the same set, a join operation can be performed to select related records
in the two tables by matching values in those fields. Often, but not always, the fields will
have the same name in both tables. For example, an “orders” table might contain (customer-
ID, product-code) pairs and a “products” table might contain (product-code, price) pairs
so to calculate a given customer’s bill you would sum the prices of all products ordered by
that customer by joining on the product-code fields of the two tables. This can be extended
to joining multiple tables on multiple fields. Because these relationships are only specified

DBA 1757
at retreival time, relational databases are classed as dynamic database management system.
NOTES The RELATIONAL database model is based on the Relational Algebra.
3. 1.4.(v).Object/Relational Model
Object/relational database management systems (ORDBMSs) add new object storage
capabilities to the relational systems at the core of modern information systems. These new
facilities integrate management of traditional fielded data, complex objects such as time-
series and geospatial data and diverse binary media such as audio, video, images, and
applets. By encapsulating methods with data structures, an ORDBMS server can execute
complex analytical and data manipulation operations to search and transform multimedia
and other complex objects.
As an evolutionary technology, the object/relational (OR) approach has inherited the
robust transaction- and performance-management features of it’s relational ancestor and
the flexibility of its object-oriented cousin. Database designers can work with familiar
tabular structures and data definition languages (DDLs) while assimilating new object-
management possibilities. Query and procedural languages and call interfaces in ORDBMSs
are familiar: SQL3, vendor procedural languages, and ODBC, JDBC, and proprietary
call interfaces are all extensions of RDBMS languages and interfaces. And the leading
vendors are, of course, quite well known: IBM, Informix, and Oracle.
3. 1.4.(vi).Object-Oriented Model
Object DBMSs add database functionality to object programming languages. They
bring much more than persistent storage of programming language objects. Object DBMSs
extend the semantics of the C++, Smalltalk and Java object programming languages to
provide full-featured database programming capability, while retaining native language
compatibility. A major benefit of this approach is the unification of the application and
database development into a seamless data model and language environment. As a result,
applications require less code, use more natural data modeling, and code bases are easier
to maintain. Object developers can write complete database applications with a modest
amount of additional effort According to Rao (1994), “The object-oriented database
(OODB) paradigm is the combination of object-oriented programming language (OOPL)
systems and persistent systems. The power of the OODB comes from the seamless treatment
of both persistent data, as found in databases, and transient data, as found in executing
program
In contrast to a relational DBMS where a complex data structure must be flattened
out to fit into tables or joined together from those tables to form the in-memory structure,
object DBMSs have no performance overhead to store or retrieve a web or hierarchy of
interrelated objects. This one-to-one mapping of object programming language objects to
database objects has two benefits over other storage approaches: it provides higher
performance management of objects, and it enables better management of the complex

interrelationships between objects. This makes object DBMSs better suited to support
applications such as financial portfolio risk analysis systems, telecommunications service NOTES
applications, world wide web document structures, design and manufacturing systems,
and hospital patient record systems, which have complex relationships between data.
3. 1.4.(vii).Context Model
The context data model combines features of all the above models. It can be considered
as a collection of object-oriented, network and semistructured models or as some kind of
object database. In other words this is a flexible model, you can use any type of database
structure depending on task. Such data model has been implemented in DBMS Context.
The fundamental unit of information storage of ConteXt is a CLASS. Class contains

METHODS and describes OBJECT. The Object contains FIELDS and PROPERTY.
The field may be composite, in this case the field contains SubFields etc. The property is a
set of fields that belongs to particular Object. In other words, fields are permanent part of
Object but Property is its variable part.
The header of Class contains the definition of the internal structure of the Object, which
includes the description of each field, such as their type, length, attributes and name. Context
data model has a set of predefined types as well as user defined types. The predefined
types include not only character strings, texts and digits but also pointers (references) and
aggregate types (structures).
Types of Fields

DBA 1757
A context model comprises three main data types: REGULAR, VIRTUAL and
NOTES REFERENCE. A regular (local) field can be ATOMIC or COMPOSITE. The atomic
field has no inner structure. In contrast, a composite field may have a complex structure,
and its type is described in the header of Class. The composite fields are divided into
STATIC and DYNAMIC. The type of a static composite field is stored in the header and
is permanent. Description of the type of a dynamic composite field is stored within the
Object and can vary from Object to Object.
Like a NETWORK database, apart from the fields containing the information directly,
context database has fields storing a place where this information can be found, i.e.
POINTER (link, reference) which can point to an Object in this or another Class. Because
main addressed unit of context database is an Object, the pointer is made to Object
instead of a field of this Object. The pointers are divided on STATIC and DYNAMIC. All
pointers that belong to a particular static pointer type point to the same Class (albeit,
possibly, to different Object). In this case, the Class name is an integral part of the that
pointer type. A dynamic pointer type describes pointers that may refer to different Classes.
The Class, which may be linked through a pointer, can reside on the same or any other
computer on the local area network. There is no hierarchy between Classes and the pointer
can link to any Class, including its own. In contrast to pure object-oriented databases,
context databases is not so coupled to the programming language and doesn’t support
methods directly. Instead, method invocation is partially supported through the concept of
VIRTUAL fields.
A VIRTUAL field is like a regular field: it can be read or written into. However, this
field is not physically stored in the database, and in it does not have a type described in the
scheme. A read operation on a virtual field is intercepted by the DBMS, which invokes a
method associated with the field and the result produced by that method is returned. If no
method is defined for the virtual field, the field will be blank. The METHODS is a subroutine
written in C++ by an application programmer. Similarly, a write operation on a virtual field
invokes an appropriate method, which can changes the value of the field. The current value
of virtual fields is maintained by a run-time process; it is not preserved between sessions.
In object-oriented terms, virtual fields represent just two public methods: reading and
writing. Experience shows, however, that this is often enough in practical applications.
From the DBMS point of view, virtual fields provide transparent interface to such methods
via an aplication written by application programer.
A context database that does not have composite or pointer fields and property is
essentially RELATIONAL. With static composite and pointer fields, context database
become OBJECT-ORIENTED. If the context database has only Property in this case it
is an ENTITY-ATTRIBUTE-VALUE database. With dynamic composite fields, a context
database becomes what is now known as a SEMISTRUCTURED database. If the
database has all available types... in this case it is Context database!

3. 1.4.(viii). Conceptual Models

NOTES
Halpin (2001) points out that many data professionals prefer to create an Object-Role
Model (ORM), an example is depicted in Figure 3, instead of an LDM for a conceptual
model. The advantage is that the notation is very simple, something your project stakeholders
can quickly grasp, although the disadvantage is that the models become large very quickly.
ORMs enable you to first explore actual data examples instead of simply jumping to a
potentially incorrect abstraction – for example Figure 3 examines the relationship between
customers and addresses in detail.
Figure 3. A simple Object-Role Model.
QUESTIONS
3.1.4.(a).What is data model?

3.1.4.(b).Explain hierarchical model and network model in detail
3.1.4.(c).What is Relational model?
3.1.4.(d).Explain object oriented model.
3.1.4.(e).What is a context model?
3.1.4.(f).Explain conceptual model I detail
SUMMARY
You have learned the concept of data model. Also you have understood the hierarchical
model, network model, Relational model, object oriented model. context model and
conceptual model in detail.
EXERCISES
1. 1.Visit a nearby hospital and discuss with the database administrator about the
management of Data bases in the hospital. Write a report describing the type of
model used and its advantages.
2. Obtain from the Internet the application of object oriented model in any firm.

DBA 1757
NOTES
CHAPTER 2
3.2 DATA MODELING
3.2.1.Introduction
The analysis of data objects and their relationships to other data objects. Data modeling
is often the first step in database design and object-oriented programming as the
designers first create a conceptual model of how data items relate to each other. Data
modeling involves a progression from conceptual model to logical model to physical schema
3.2.2.Learning Objectives
• After reading this chapter, you will be able to understand

• What is meant by data modeling?
• What are the common data modeling notations
• How to model data/
3.2.3. Common Data Modeling Notations
Figure 4 presents a summary of the syntax of four common data modeling notations:
Information Engineering (IE), Barker, IDEF1X, and the Unified Modeling Language
(UML). This diagram isn’t meant to be comprehensive, instead its goal is to provide a
basic overview.

Figure 4. Comparing the syntax of common data modeling notations.
73
NOTES
ANNA UNIVERSITY CHENNAI

DBA 1757
The common data modeling notations are discussed below.

NOTES
Table 3.2.1. Discussing common data modeling notations.
3.2.4 How to Model Data
It is critical for an application developer to have a grasp of the fundamentals of data

modeling so they can not only read data models but also work effectively with Agile DBAs
who are responsible for the data-oriented aspects of your project. Your goal reading this
section is not to learn how to become a data modeler, instead it is simply to gain an
appreciation of what is involved.
The following tasks are performed in an iterative manner:

• Identify entity types
• Identify attributes
• Apply naming conventions
• Identify relationships
• Apply data model patterns
• Assign keys

• Normalize to reduce data redundancy

• Denormalize to improve performance NOTES
3.2.4.(i). Identify Entity Types
An entity type, also simply called entity (not exactly accurate terminology, but very
common in practice), is similar conceptually to object-orientation’s concept of a class – an
entity type represents a collection of similar objects. An entity type could represent a
collection of people, places, things, events, or concepts. Examples of entities in an order
entry system would include Customer, Address, Order, Item, and Tax. If you were class
modeling you would expect to discover classes with the exact same names. However, the
difference between a class and an entity type is that classes have both data and behaviour
whereas entity types just have data.
Ideally an entity should be normal, the data modeling world’s version of cohesive. A
normal entity depicts one concept, just like a cohesive class models one concept. For
example, customer and order are clearly two different concepts; therefore it makes sense
to model them as separate entities.
3.2.4.(ii). Identify Attributes
Each entity type will have one or more data attributes.
For example, in Figure 1 you saw that the Customer entity has attributes such as
First Name and Surname and in Figure 2 that the TCUSTOMER table had corresponding
data columns CUST_FIRST_NAME and CUST_SURNAME (a column is the
implementation of a data attribute within a relational database).
Attributes should also be cohesive from the point of view of your domain, something
that is often a judgment call. – in Figure 1 we decided that we wanted to model the fact that
people had both first and last names instead of just a name (e.g. “Scott” and “Ambler” vs.
“Scott Ambler”) whereas we did not distinguish between the sections of an American zip
code (e.g. 90210-1234-5678). Getting the level of detail right can have a significant
impact on your development and maintenance efforts. Refactoring a single data column
into several columns can be difficult, database refactoring is described in detail in Database
Refactoring, although over-specifying an attribute (e.g. having three attributes for zip code
when you only needed one) can result in overbuilding your system and hence you incur
greater development and maintenance costs than you actually needed.
3.2.4.(iii). Apply Data Naming Conventions
Your organization should have standards and guidelines applicable to data modeling,
something you should be able to obtain from your enterprise administrators (if they don’t
exist you should lobby to have some put in place). These guidelines should include naming
conventions for both logical and physical modeling, the logical naming conventions should
be focused on human readability whereas the physical naming conventions will reflect

DBA 1757
technical considerations. You can clearly see that different naming conventions were applied
NOTES in Figures 1 and 2.
As you saw in Introduction to Agile Modeling, AM includes the Apply Modeling
Standards practice. The basic idea is that developers should agree to and follow a common
set of modeling standards on a software project. Just like there is value in following common
coding conventions, clean code that follows your chosen coding guidelines is easier to
understand and evolve than code that doesn’t, there is similar value in following common
modeling conventions.
3.2.4.(iv).Identify Relationships
In the real world entities have relationships with other entities. For example, customers
PLACE orders, customers LIVE AT addresses, and line items ARE PART OF orders.
Place, live at, and are part of are all terms that define relationships between entities. The
relationships between entities are conceptually identical to the relationships (associations)
between objects.
Figure 5 depicts a partial LDM for an online ordering system. The first thing to notice
is the various styles applied to relationship names and roles – different relationships require
different approaches. For example the relationship between Customer and Order has
two names, places and is placed by, whereas the relationship between Customer and
Address has one. In this example having a second name on the relationship, the idea being
that you want to specify how to read the relationship in each direction, is redundant –
you’re better off to find a clear wording for a single relationship name, decreasing the
clutter on your diagram. Similarly you will often find that by specifying the roles that an
entity plays in a relationship will often negate the need to give the relationship a name. For
example the role of billing address and the label billed to are clearly redundant, you really
only need one. For example the role part of that Line Item has in its relationship with
Order is sufficiently obvious without a relationship name.

NOTES
Figure 5. A logical data model (Information Engineering notation).

You also need to identify the cardinality and optionality of a relationship (the UML
combines the concepts of optionality and cardinality into the single concept of multiplicity).
Cardinality represents the concept of “how many” whereas optionality represents the
concept of “whether you must have something.” For example, it is not enough to know that
customers place orders. How many orders can a customer place? None, one, or several?
Furthermore, relationships are two-way streets: not only do customers place orders, but
orders are placed by customers. This leads to questions like: how many customers can be
enrolled in any given order and is it possible to have an order with no customer involved?
Figure 5 shows that customers place one or more orders and that any given order is
placed by one customer and one customer only. It also shows that a customer lives at one
or more addresses and that any given address has zero or more customers living at it.
Although the UML distinguishes between different types of relationships – associations,

inheritance, aggregation, composition, and dependency – data modelers often aren’t as
concerned with this issue as much as object modelers are. Subtyping, one application of
inheritance, is often found in data models, an example of which is the is a relationship
between Item and it’s two “sub entities” Service and Product. Aggregation and composition
are much less common and typically must be implied from the data model, as you see with
the part of role that Line Item takes with Order. UML dependencies are typically a
software construct and therefore wouldn’t appear on a data model, unless of course it was
a very highly detailed physical model that showed how views, triggers, or stored procedures
depended on other aspects of the database schema.
3.2.4.(v). Apply Data Model Patterns
Some data modelers will apply common data model patterns. Data model patterns
are conceptually closest to analysis patterns because they describe solutions to common
omain issues.

DBA 1757
3.2.4.(vi).Assign Keys
NOTES
There are two fundamental strategies for assigning keys to tables. First, you could
assign a natural key which is one or more existing data attributes that are unique to the
business concept. The Customer table of Figure 6 there was two candidate keys, in this
case CustomerNumber and SocialSecurityNumber. Second, you could introduce a
new column, called a surrogate key, which is a key that has no business meaning. An
example of which is the AddressID column of the Address table in Figure 6. Addresses
don’t have an “easy” natural key because you would need to use all of the columns of the
Address table to form a key for itself (you might be able to get away with just the
combination of Street and ZipCode depending on your problem domain), therefore
introducing a surrogate key is a much better option in this case.
Figure 6. Customer and Address revisited (UML notation).
Let’s consider Figure 6 in more detail. Figure 6 presents an alternative design to that
presented in Figure 2, a different naming convention was adopted and the model itself is
more extensive. In Figure 6 the Customer table has the CustomerNumber column as its
primary key and SocialSecurityNumber as an alternate key. This indicates that the
preferred way to access customer information is through the value of a person’s customer
number although your software can get at the same information if it has the person’s social
security number. The CustomerHasAddress table has a composite primary key, the
combination of CustomerNumber and AddressID. A foreign key is one or more attributes
in an entity type that represents a key, either primary or secondary, in another entity type.
Foreign keys are used to maintain relationships between rows. For example, the
relationships between rows in the CustomerHasAddress table and the Customer table is
maintained by the CustomerNumber column within the CustomerHasAddress table. The
interesting thing about the CustomerNumber column is the fact that it is part of the primary
key for CustomerHasAddress as well as the foreign key to the Customer table. Similarly,
the AddressID column is part of the primary key of CustomerHasAddress as well as a
foreign key to the Address table to maintain the relationship with rows of Address.

Although the “natural vs. surrogate” debate is one of the great religious issues within the
data community, the fact is that neither strategy is perfect and you’ll discover that in practice NOTES
(as we see in Figure 6) sometimes it makes sense to use natural keys and sometimes it
makes sense to use surrogate keys.
3.2.4.(vii). Normalize to Reduce Data Redundancy
Data normalization is a process in which data attributes within a data model are
organized to increase the cohesion of entity types. In other words, the goal of data
normalization is to reduce and even eliminate data redundancy, an important consideration
for application developers because it is incredibly difficult to stores objects in a relational
database that maintains the same information in several places. Table 2 summarizes the
three most common normalization rules describing how to put entity types into a series of
increasing levels of normalization. Higher levels of data normalization are beyond the
scope of this book. With respect to terminology, a data schema is considered to be at the
level of normalization of its least normalized entity type. For example, if all of your entity
types are at second normal form (2NF) or higher then we say that your data schema is at
2NF.
Table 2. Data Normalization Rules.
Figure 7 depicts a database schema in ONF whereas Figure 8 depicts a normalized

schema in 3NF.
Why data normalization? The advantage of having a highly normalized data schema
is that information is stored in one place and one place only, reducing the possibility of
inconsistent data. Furthermore, highly-normalized data schemas in general are closer
conceptually to object-oriented schemas because the object-oriented goals of promoting
high cohesion and loose coupling between classes results in similar solutions . This generally
makes it easier to map your objects to your data schema. Unfortunately, normalization
usually comes at a performance cost. With the data schema of Figure 7 all the data for a
single order is stored in one row (assuming orders of up to nine order items), making it
very easy to access. With the data schema of Figure 7 you could quickly determine the
total amount of an order by reading the single row from the Order0NF table. To do so .

DBA 1757
NOTES
Figure 7. An Initial Data Schema for Order (UML Notation).

NOTES
Figure 8. A normalized schema in 3NF (UML Notation).

DBA 1757
with the data schema of Figure 8 you would need to read data from a row in the Order
NOTES table, data from all the rows from the OrderItem table for that order and data from the
corresponding rows in the Item table for each order item. For this query, the data schema
of Figure 7 very likely provides better performance.
3.2.4.(h). Denormalize to Improve Performance
Normalized data schemas, when put into production, often suffer from performance
problems. This makes sense – the rules of data normalization focus on reducing data
redundancy, not on improving performance of data access. An important part of data
modeling is to denormalize portions of your data schema to improve database access
times. For example, the data model of Figure 9 looks nothing like the normalized schema
of Figure 8. To understand why the differences between the schemas exist you must
consider the performance needs of the application. The primary goal of this system is to
process new orders from online customers as quickly as possible. To do this customers
need to be able to search for items and add them to their order quickly, remove items from
their order if need be, then have their final order totaled and recorded quickly. The secondary
goal of the system is to the process, ship, and bill the orders afterwards.
Figure 9. A Denormalized Order Data Schema (UML notation).

To denormalize the data schema the following decisions were made:

NOTES
1. To support quick searching of item information the Item table was left alone.
2. To support the addition and removal of order items to an order the concept of an
OrderItem table was kept, albeit split in two to support outstanding orders and fulfilled
orders. New order items can easily be inserted into the OutstandingOrderItem table,
or removed from it, as needed.
3. To support order processing the Order and OrderItem tables were reworked into
pairs to handle outstanding and fulfilled orders respectively. Basic order information is
first stored in the OutstandingOrder and OutstandingOrderItem tables and then
when the order has been shipped and paid for the data is then removed from those
tables and copied into the FulfilledOrder and FulfilledOrderItem tables respectively.
Data access time to the two tables for outstanding orders is reduced because only the
active orders are being stored there. On average an order may be outstanding for a
couple of days, whereas for financial reporting reasons may be stored in the fulfilled
order tables for several years until archived. There is a performance penalty under this
scheme because of the need to delete outstanding orders and then resave them as
fulfilled orders, clearly something that would need to be processed as a transaction.
4. The contact information for the person(s) the order is being shipped and billed to was
also denormalized back into the Order table, reducing the time it takes to write an
order to the database because there is now one write instead of two or three. The
retrieval and deletion times for that data would also be similarly improved.
Note that if your initial, normalized data design meets the performance needs of your
application then it is fine as is. Denormalization should be resorted to only when performance
testing shows that you have a problem with your objects and subsequent profiling reveals
that you need to improve database access time.
3.2.5.Evolutionary/Agile Data Modeling
Evolutionary data modeling is data modeling performed in an iterative and incremental

manner. Agile data modeling is evolutionary data modeling done in a collaborative manner.
Although you wouldn’t think it, data modeling can be one of the most challenging tasks that
an Agile DBA can be involved with on an agile software development project. Your
approach to data modeling will often be at the center of any controversy between the agile
software developers and the traditional data professionals within your organization. Agile
software developers will lean towards an evolutionary approach where data modeling is
just one of many activities whereas traditional data professionals will often lean towards a
big design up front (BDUF) approach where data models are the primary artifacts, if not
THE artifacts. This problem results from a combination of the cultural impedance mismatch,
a misguided need to enforce the “one truth”, and “normal” political maneuvering within
your organization. As a result Agile DBAs often find that navigating the political waters is
an important part of their data modeling efforts.

DBA 1757
How do you improve your data modeling skills? Practice, practice, practice. Whenever
NOTES you get a chance you should work closely with Agile DBAs, volunteer to model data with
them, and ask them questions as the work progresses. One of the best ways to really learn
your craft is to have someone as “why are you doing it that way”. You should be able to
learn physical data modeling skills from Agile DBAs, and often logical data modeling skills
as well.
QUESTIONS
3.2.4.(a).What are the Data Modeling Notations available ? Discuss in detail.

3.2.4.(b).Explain the detailed procedure to model data.
3.2.4.(c). Explain Evolutionary Data Modeling
SUMMARY
You have learned how data modeling notations can be applied. Also you would have
understand the detailed procedure to model data.

NOTES
CHAPTER 3
3.3 NORMALIZATION
3.3.1. Introduction
Normalization is the process of organizing data in a database. This includes creating

tables and establishing relationships between those tables according to rules designed both
to protect the data and to make the database more flexible by eliminating redundancy and
inconsistent dependency.
Redundant data wastes disk space and creates maintenance problems. If data that
exists in more than one place must be changed, the data must be changed in exactly the
same way in all locations. A customer address change is much easier to implement if that
data is stored only in the Customers table and nowhere else in the database.
3.3.2.LEARNING OBJECTIVES
After reading this chapter, you should be able to understand

• Data Normalization
• Rules of Data Normalization
• Boyce-Codd Normal form.
3.3.3.Rules of Data Normalization
There are a few rules for database normalization. Each rule is called a “normal form.”
If the first rule is observed, the database is said to be in “first normal form.” If the first three
rules are observed, the database is considered to be in “third normal form.” Although other
levels of normalization are possible, third normal form is considered the highest level
necessary for most applications.
As with many formal rules and specifications, real world scenarios do not always
allow for perfect compliance. In general, normalization requires additional tables and some
customers find this cumbersome. If you decide to violate one of the first three rules of
normalization, make sure that your application anticipates any problems that could occur,
such as redundant data and inconsistent dependencies.

DBA 1757
NOTES
1. Eliminate Repeating Groups

In the original member list, each member name is followed by any databases that the
member has experience with. Some might know many, and others might not know any. To
answer the question, “Who knows DB2?” we need to perform an awkward scan of the list
looking for references to DB2. This is inefficient and an extremely untidy way to store
information.
Moving the known databases into a separate table helps a lot. Separating the repeating
groups of databases from the member information results in First Normal form (1NF). The
Member ID in the database table matches the primary key in the member table, providing
a foreign key for relating the two tables with a join operation. Now we can answer the
question by looking in the database table for “DB2” and getting the list of members.

NOTES
2. Eliminate Redundant Data

In the Database Table, the primary key is made up of the MemberID and the
DatabaseID. This makes sense for other attributes like “Where Learned” and “Skill Level”
attributes, since they will be different for every member/database combination. But the
database name depends only on the DatabaseID. The same database name will appear
redundantly every time its associated ID appears in the Database Table.
Suppose you want to reclassify a database - give it a different DatabaseID. The change
has to be made for every member that lists that database! If you miss some, you’ll have
several members with the same database under different IDs. This is an update anomaly.
Or suppose the last member listing a particular database leaves the group. His records
will be removed from the system, and the database will not be stored anywhere! This is a
delete anomaly. To avoid these problems, we need second normal form.
To achieve this, separate the attributes depending on both parts of the key from those
depending only on the DatabaseID. This results in two tables: “Database” which gives the
name for each DatabaseID, and “MemberDatabase” which lists the databases for each
member.
Now we can reclassify a database in a single operation: look up the DatabaseID in
the “Database” table and change its name. The result will instantly be available throughout
the application.

DBA 1757
3. Eliminate Columns Not Dependent On Key

NOTES
The Member table satisfies first normal form - it contains no repeating groups. It
satisfies second normal form - since it doesn’t have a multivalued key. But the key is
MemberID, and the company name and location describe only a company, not a member.
To achieve third normal form, they must be moved into a separate table. Since they describe
a company, CompanyCode becomes the key of the new “Company” table.
The motivation for this is the same for second normal form: we want to avoid update
and delete anomalies. For example, suppose no members from the IBM were currently
stored in the database. With the previous design, there would be no record of its existence,
even though 20 past members were from IBM!
BCNF. Boyce-Codd Normal Form
Boyce-Codd Normal Form states mathematically that:A relation R is said to be in

BCNF if whenever X -> A holds in R, and A is not in X, then X is a candidate key for
R.BCNF covers very specific situations where 3NF misses inter-dependencies between
non-key (but candidate key) attributes. Typically, any relation that is in 3NF is also in
BCNF. However, a 3NF relation won’t be in BCNF if (a) there are multiple candidate
keys, (b) the keys are composed of multiple attributes, and (c) there are common attributes
between the keys.
Basically, a humorous way to remember BCNF is that all functional dependencies

are:”The key, the whole key, and nothing but the key, so help me Codd.”
4. Isolate Independent Multiple Relationships
This applies primarily to key-only associative tables, and appears as a ternary

relationship, but has incorrectly merged 2 distinct, independent relationships.
The way this situation starts is by a business request list the one shown below. This
could be any 2 M:M relationships from a single entity. For instance, a member could know
many software tools, and a software tool may be used by many members. Also, a member
could have recommended many books, and a book could be recommended by many
members.

NOTES
Initial business request
So, to resolve the two M:M relationships, we know that we should resolve them
separately, and that would give us 4th normal form. But, if we were to combine them into
a single table, it might look right (it is in 3rd normal form) at first. This is shown below, and
violates 4th normal form.
Incorrect solution
To get a picture of what is wrong, look at some sample data, shown below. The first
few records look right, where Bill knows ERWin and recommends the ERWin Bible for
everyone to read. But something is wrong with Mary and Steve. Mary didn’t recommend
a book, and Steve Doesn’t know any software tools. Our solution has forced us to do
strange things like create dummy records in both Book and Software to allow the record
in the association, since it is key only table.

DBA 1757
Sample data from incorrect solution

NOTES
The correct solution, to cause the model to be in 4th normal form, is to ensure that all
M:M relationships are resolved independently if they are indeed independent, as shown
below.
Correct 4th normal form
NOTE! This is not to say that ALL ternary associations are invalid. The above situation
made it obvious that Books and Software were independently linked to Members. If,
however, there were distinct links between all three, such that we would be stating that
“Bill recommends the ERWin Bible as a reference for ERWin”, then separating the
relationship into two separate associations would be incorrect. In that case, we would lose
the distinct information about the 3-way relationship.
5. Isolate Semantically Related Multiple Relationships
OK, now lets modify the original business diagram and add a link between the books
and the software tools, indicating which books deal with which software tools, as shown
below.
Initial business request
This makes sense after the discussion on Rule 4, and again we may be tempted to
resolve the multiple M:M relationships into a single association, which would now violate
5th normal form. The ternary association looks identical to the one shown in the 4th normal

form example, and is also going to have trouble displaying the information correctly. This
time we would have even more trouble because we can’t show the relationships between NOTES
books and software unless we have a member to link to, or we have to add our favorite
dummy member record to allow the record in the association table.
Incorrect solution
The solution, as before, is to ensure that all M:M relationships that are independent
are resolved independently, resulting in the model shown below. Now information about
members and books, members and software, and books and software are all stored
independently, even though they are all very much semantically related. It is very tempting
in many situations to combine the multiple M:M relationships because they are so similar.
Within complex business discussions, the lines can become blurred and the correct solution
not so obvious.
Correct 5th normal form
6. Optimal Normal Form
At this point, we have done all we can with Entity-Relationship Diagrams (ERD).
Most people will stop here because this is usually pretty good. However, another modeling
style called Object Role Modeling (ORM) can display relationships that cannot be expressed
in ERD. Therefore there are more normal forms beyond 5th. With Optimal Normal Form
(OMF)It is defined as a model limited to only simple (elemental) facts, as expressed in
ORM.

DBA 1757
7. Domain-Key Normal Form

NOTES
This level of normalization is simply a model taken to the point where there are no
opportunities for modification anomalies.
9 “if every constraint on the relation is a logical consequence of the definition of
keys and domains”
9 Constraint “a rule governing static values of attributes”
9 Key “unique identifier of a tuple”
9 Domain “description of an attribute’s allowed values”
1. A relation in DK/NF has no modification anomalies, and conversely.
2. DK/NF is the ultimate normal form; there is no higher normal form related to
modification anomalies
3. Defn: A relation is in DK/NF if every constraint on the relation is a logical
consequence of the definition of keys and domains.
4. Constraint is any rule governing static values of attributes that is precise enough to
be ascertained whether or not it is true
5. E.g. edit rules, intra-relation and inter-relation constraints, functional and multi-
valued dependencies.
6. Not including constraints on changes in data values or time-dependent constraints.
7. Key - the unique identifier of a tuple.
8. Domain: physical and a logical description of an attributes allowed values.
9. Physical description is the format of an attribute.
10. Logical description is a further restriction of the values the domain is allowed
11. Logical consequence: find a constraint on keys and/or domains which, if it is
enforced, means that the desired constraint is also enforced.
12. Bottom line on DK/NF: If every table has a single theme, then all functional
dependencies will be logical consequences of keys. All data value constraints can
them be expressed as domain constraints.
13. Practical consequence: Since keys are enforced by the DBMS and domains are
enforced by edit checks on data input, all modification anomalies can be avoided
by just these two simple measures.
QUESTIONS
3.3.3(a).Define Normalization of Database.
3.3.3(b).Why Normalization is required?
3.3.3(c).Explain the rules for Normalization.
3.3.3(d).Explain 1NF and 2NF Normal form.
3.3.3(e). Explain Boyce code Normal form.
3.3.3(f). Explain Optimal Normal Form and Domain-Key Normal Form.
SUMMARY
Your have learned the Normalization Rules and Techniques of database in a detailed
manner.

EXERCISES
NOTES
3.3.3 (i) Collect the below mentioned fields data for 5 years from a nearby hospital or
browse in the net and normalize .
Name of the Hospital , Address. Founder ,Year of Establishment
Doctors details includes Name of the Dr.s, D.O.B., Age, Sex, Qualification,
Specialization, Experience, Research Experience.
Name of the patients, Patients Id, Type of Patients(whether In Patient or Out Patient),
Age, Sex, Marital status ,Qualification, Type of disease.

DBA 1757
CHAPTER 4
NOTES
3.4 DATA MINING AND DESIGN PROCESS
3.4.1.Introduction
Data mining is sorting through data to identify patterns and establish relationships.
Data mining parameters include:
• Association - looking for patterns where one event is connected to another event
• Sequence or path analysis - looking for patterns where one event leads to another
later event
• Classification - looking for new patterns (May result in a change in the way the
data is organized but that’s ok)
• Clustering - finding and visually documenting groups of facts not previously known
• Forecasting - discovering patterns in data that can lead to reasonable predictions
about the future (This area of data mining is known as

• This chapter teaches you about
• What is Data Warehousing?
• What is DATA Mining.
• Data Mining Tools
• Types of Healthcare data
• Meta data and data quality.
3.4.3. Data Warehousing
The term Data Warehouse has been defined as “A warehouse is a subject-oriented,
integrated, time-variant and non-volatile collection of data in support of management’s
decision making process”.
3.4.3.(i) What do you mean by Data Warehousing?

The Oracle database used by Banner is designed for OnLine Transaction Processing
(OLTP). A data warehouse is designed for a different purpose. It is designed to support ad
hoc data analysis, inquiry and reporting by end users, without programmers, interactively
and online. This is called OnLine Analytical Processing (OLAP), or Multi-Dimensional
Analysis. It is more than just a better set of reports. Mostly for performance reasons, a
data warehouse is held in a separate database from the operational database, usually on a
separate machine.
3.4.3.(ii). Why do we need it?
The Banner database is designed to be efficient at processing online transactions, and this
kind of design is quite inefficient at processing analytical queries and ad hoc reports. This
gives frustrating performance for the person making the inquiry, as well as having a significant
impact on the performance of the system for regular Banner users.

But there is an even more important reason for building a data warehouse. The structure
of the OLTP database is almost incomprehensible to anyone but a programmer. Rules of NOTES
OTLP database design are broken in a data warehouse to make navigation through the
subject areas and data elements correspond to business functions, thus making a data
warehouse more intuitive to use.
This results in at least the possibility of being able to ask questions about the data that
can be answered without calling on a programmer.
The following table summarizes some of the main benefits that are possible through
data warehousing.
Table 1. Benefits of Data Warehousing[1]
3.4.3.(iii) How do we get it?
Some of the key factors to consider when building a data warehouse are listed in the
following table:

DBA 1757
Table 2 Key Ingredients for Data Warehousing Success

NOTES
There is a process for choosing strategically important subject areas that starts with
the mission statement of the institution, and the goals and objectives. Critical success factors
are then identified, as well as the steps for achieving success as outlined in the strategic
plan. Indicators are found that can be measured and that can be used to monitor the
success of the plan, especially in the areas deemed critical, and also adherence to the plan.
These are called key performance indicators, and these form the basis of analytical data
models that are provided in the data warehouse.

3.4.3.(iv). Data mining/Statistics

NOTES
With the proliferation of data warehouses, data mining tools are flooding the market.
Their objective is to discover hidden gold in your data. Many traditional report and query
tools and statistical analysis systems use the term “data mining” in their product descriptions.
The ultimate objective of data mining is knowledge discovery. Data mining methodology
extracts hidden predictive information from large databases. With such a broad definition,
however, an online analytical processing (OLAP) product or a statistical package could
qualify as a data mining tool.
Data mining methodology extracts hidden predictive information from large databases.
That’s where technology comes in: for true knowledge discovery a data mining tool
should unearth hidden information automatically. By this definition data mining is data-
driven, not user-driven or verification-driven.
3.4.3.(v).The Ten Steps of Data Mining
Here is a process for extracting hidden knowledge from your data warehouse, your
customer information file, or any other company database.
1. Identify The Objective
Before you begin, be clear on what you hope to accomplish with your analysis. Know
in advance the business goal of the data mining. Establish whether or not the goal is
measurable. Some possible goals are to
find sales relationships between specific products or services

dentify specific purchasing patterns over time
identify potential types of customers
find product sales trends.
2. Select The Data
Once you have defined your goal, your next step is to select the data to meet this
goal. This may be a subset of your data warehouse or a data mart that contains specific
product information. It may be your customer information file. Segment as much as possible
the scope of the data to be mined.
Here are some key issues
Are the data adequate to describe the phenomena the data mining analysis is attempting
to model?
Can you enhance internal customer records with external lifestyle and demographic
data?

DBA 1757
Are the data stable—will the mined attributes be the same after the analysis?
NOTES
If you are merging databases can you find a common field for linking them?
How current and relevant are the data to the business goal?
3. Prepare The Data
Once you’ve assembled the data, you must decide which attributes to convert into
usable formats. Consider the input of domain experts—creators and users of the data.
Establish strategies for handling missing data, extraneous noise, and outliers
Identify redundant variables in the dataset and decide which fields to exclude
Decide on a log or square transformation, if necessary
Visually inspect the dataset to get a feel for the database
Determine the distribution frequencies of the data
You can postpone some of these decisions until you select a data mining tool. For
example, if you need a neural network or polynomial network you may have to transform
some of your fields.
4.Audit The Data
Evaluate the structure of your data in order to determine the appropriate tools.
What is the ratio of categorical/binary attributes in the database?
What is the nature and structure of the database?
What is the overall condition of the dataset?
What is the distribution of the dataset?
Balance the objective assessment of the structure of your data against your users’
need to understand the findings. Neural nets, for example, don’t explain their results.
5. Select The Tools
Two concerns drive the selection of the appropriate data mining tool—your business
objectives and your data structure. Both should guide you to the same tool.
Consider these questions when evaluating a set of potential tools.
Is the data set heavily categorical?
What platforms do your candidate tools support?

· Are the candidate tools ODBC-compliant?

NOTES
· What data format can the tools import?
No single tool is likely to provide the answer to your data mining project. Some tools
integrate several technologies into a suite of statistical analysis programs, a neural network,
and a symbolic classifier.
6. Format The Solution
In conjunction with your data audit, your business objective and the selection of your
tool determine the format of your solution
The Key questions are
What is the optimum format of the solution—decision tree, rules, C code, SQL syntax?
What are the available format options?
What is the goal of the solution?
What do the end-users need—graphs, reports, code?
7. Construct The Model
At this point that the data mining process begins. Usually the first step is to use a random
number seed to split the data into a training set and a test set and construct and evaluate a
model. The generation of classification rules, decision trees, clustering sub-groups, scores,
code, weights and evaluation data/error rates takes place at this stage. Resolve these
issues:
Are error rates at acceptable levels? Can you improve them?

What extraneous attributes did you find? Can you purge them?
Is additional data or a different methodology necessary?
Will you have to train and test a new data set?
8. Validate The Findings
Share and discuss the results of the analysis with the business client or domain expert.
Ensure that the findings are correct and appropriate to the business objectives.
Do the findings make sense?
Do you have to return to any prior steps to improve results?
Can use other data mining tools to replicate the findings?

DBA 1757
9. Deliver The Findings

NOTES
Provide a final report to the business unit or client. The report should document the
entire data mining process including data preparation, tools used, test results, source code,
and rules. Some of the issues are:
Will additional data improve the analysis?
What strategic insight did you discover and how is it applicable?
What proposals can result from the data mining analysis?
Do the findings meet the business objective?
10. Integrate The Solution
Share the findings with all interested end-users in the appropriate business units. You
might wind up incorporating the results of the analysis into the company’s business
procedures. Some of the data mining solutions may involve
SQL syntax for distribution to end-users
C code incorporated into a production system
Rules integrated into a decision support system.
Although data mining tools automate database analysis, they can lead to faulty findings
and erroneous conclusions if you’re not careful. Bear in mind that data mining is a business
process with a specific goal—to extract a competitive insight from historical records in a
database.
3.4.3.(vi). Data Mining Tools
Larry Greenfield lists the following categories of data mining tools:

• Case-Based Reasoning
• Data Visualization
• Fuzzy Query and Analysis
• Knowledge Discovery
• Neural Networks

Dimensions of data mining contexts and examples

NOTES
3.4.3.(vii) Data mining and design process
These stages are preparation, data analysis and business rules, data cleansing, progress
tracking and sustainment. These stages are shown as a linear progression instead of a
circle. Once an emerging system goes live, any data quality initiatives then fall under the
basic data quality process. This means that unlike the earlier data quality plan referenced
this does actually have an end point.
The data quality review for an emerging system is somewhat different from that of an
existing system and is better labeled as a data cleansing effort. All the data residing in the
legacy system and any interfacing systems will be cleansed for Accuracy, Currency,
Consistency and Completeness prior to conversion to the emerging system.
The data cleansing process for emerging systems consists of five stages: Preparation
Stage, Data Analysis and Business Rules, Data Cleansing, Progress Tracking, and
Sustainment.
Figure 3 - Data Cleansing Process Compare

DBA 1757
Stage 1: Preparation
NOTES
A data cleansing team is established consisting of subject matter experts from the
interfacing system, the emerging system PMO and the Data Integrity Office. A data cleansing
team lead will be appointed to conduct meetings and ensure all members of the team are
kept abreast of the data cleansing process to be performed.
Once the data cleansing team is established, the team will review the requirements of
the emerging system and begin identifying data elements that will reside in the new system.
A roadmap will be created to show these data elements and where they currently reside.
After the roadmap is developed, the data cleansing team will document priorities and
expected performance standards of the emerging system. The following are examples of
concerns that may need to be addressed:
What primary data elements will be in the first release?
What will good data look like as opposed to bad?

Are the data elements in the interfacing systems going to show up exactly the same in
the emerging system or will field names, acceptable characters, and definitions be changing?
What data quality issues exist in the interfacing systems that may pose a problem to
the emerging system?
Stage 2: Data Analysis and Business Rule Creation
The data cleansing team will identify data issues (data problems) and compare the
data against the four data quality characteristics, Accuracy, Consistency, Currency and
Completeness.
The following are additional concerns that may need to be addressed when reviewing
the four data quality characteristics:
First, the team will review the data elements for accuracy, to see if the data is being
represented correctly.
Second, the team will review the data for consistency. In theory, the emerging system
will perform or process data differently than its legacy system. Field lengths, what the data
elements actually mean and how they are presented may cause differences during the
conversion process. A review of consistency is therefore two fold. The data element must
be consistent among all the interfacing systems and must convert into the proper format in
the new system.

Third, the team will review the data for currency. When multiple systems are involved,
special care will be taken when determining which system contains the current data. NOTES
Reviewing outdated data is not practical unless the emerging system itself is simply a historical
data warehouse.
Finally the team will review the data for Completeness. The team will ensure all of the
data required from the legacy system makes the transfer to the emerging system. If the
emerging system requires a certain data element to be mandatory but the legacy system
did not, then there will be incomplete data that will need to be generated by other means.
Based on the data issues identified during this stage, the team will develop a root
cause analysis to determine whether the causes are systemic or manual. This will help
determine what corrective actions are needed. Because systemic corrections can be done
easier and quicker, the PMO may decide to take care of these problems first.
Once the team has identified the issues and causes, business rules will be developed to
provide the standard for the data elements that the new system is trying to obtain. Business
rules show what is a good value for that data element, who will fix it and how it will be
fixed.
The team will create business rules for accuracy and for the conversion (consistency
and completeness) of data. This may require the team to develop new system edits, as well
as mock conversions to ensure the data will transfer correctly.
A mock conversion is run in a test database. It utilizes a snap shot of the data provided
by an interfacing system. The data is run through an identical process as if it were going into
the production database. Afterwards, the data is checked and any discrepancies identified
are reviewed. These mock conversions can identify new problems and help refine the
business rules as needed.
Stage 3: Data Cleansing
In this stage the team will take the necessary actions to implement improvements/
corrective actions. This stage is very similar to the implementation step for a System/
Product DQ review, however, the corrections being implemented here follow business
rules and are usually accomplished as releases. Because the data corrections will be
accomplished in releases, implementing improvements will be repeated as needed and
adjusted to the scheduling of each release. As each new release is prepared, new
improvements may need to be made against the existing business rules or new rules may
need to be created.
A number of errors uncovered during the review of the interfacing systems will be
errors in the pre-existing data. These errors need to be corrected by the authoritative
source prior to the data being released to the emerging system. This is especially important

DBA 1757
if the interfacing system will be a continuous feeder of data to the emerging system. Not all
NOTES possible errors in a given release can be determined in advance. The team will need to
analyze the complete release once it’s in the emerging system. The team will utilize automated
queries and reject notification edits to obtain the identified rejects.
The team will determine if any new business rules need to be added or if any of the
ones previously drafted need to be amended to address unique or unexpected situations.
New or amended rules must be implemented to the data quality testing and cleansing
practices. The team will also need to determine if any special cleansing efforts are needed
for data that has already made it into the emerging system.
Stage 4: Progress Tracking
The team will determine what types of reports are required to track the results of
each release and provide status to project sponsors and management. The team may
decide to utilize a generalized reporting structure for reporting purposes. There are actual
examples of this structure in the DQM. This will require a number of charts or graphs
requested by the PMO to show the general progress of the data cleansing effort. Reports
should include status such as:
Overall actions.
Breakdown of actions per systems.
Balance left to be cleansed.
Items added or deleted.
Items that failed to meet a business rule and therefore did not make it into the new
system intact.
Actions that need to be added or deleted to another release.
Actions that need to be set aside that set of information for further review and
instruction.
The team should be prepared for unexpected situations that may occur during a release
and be able to adjust their reporting technique to reflect the applicable information.
Other reporting documents such as the System/Product DQ Baseline Chart or the

System/Product Action Plan may also be utilized for reporting purposes.
Establishing timeframes for reporting is just as important as the reporting criteria and may
be altered throughout the life cycle of the releases. At the beginning of the project the team
will establish timeframes for the reports to coincide with the major accomplishments of
system development. For each release, the timeframes for reporting may be re-adjusted
accordingly.

Stage 5: Sustainment
NOTES
Once the final release is complete, there may still be work for the data cleansing
group to perform. Due to the press of time or resources some errors may still exist from
earlier releases. These errors may not have been considered substantial enough to fix at
the time, but need to be revisited now for possible corrective actions.
Based on the established business rules as well as the internal edits of the new system, the
team will also perform testing on the data to ensure that the standards were met. A series
of follow-up testing should be performed and documented to ensure everything is as it
should be.
Finally, once the system is in sustainment, it can be added to the list of Targeted
Systems/Programs scheduled to undergo a DQ System/Product review
QUESTIONS
3.4.3.(a).Define Data warehousing.
3.4.3.(b).Define Data mining.
3.4.3.(c).Explain the 10 steps of Data mining with example.
3.4.3.(d). Explain the Data mining Tools.
3.4.4. Types of Healthcare Data
3. 4.4.(i). Classification System
Data classification is a simple concept. It is a scheme by which the organization assigns

a level of sensitivity and an owner to each piece of information that it owns and maintains.
Storage and retrieval of numerous data devoted to handling extensive and integrated
classification systems. In a hospital, for example, a data classification scheme would identify
the sensitivity of every piece of data in the hospital, from the cafeteria menu to patient
medical records. Classification systems are defined and stored independently of any
particular table of data, and can be simply linked to the relevant fields in the data. Extensions
or revisions to the classification systems are thus instantly available across all the data
collections.
The need for such an extensive classification system is clear when you consider the
various ways of grouping and comparison of similar data, or consider the varying ways of
how to use the International Classification of Disease
In addition, many standard classifications - such as the Health Priority Areas or the Refined
Diagnosis Related Groups - are included as recodes in the classification system, allowing
users to explore the library in the way most suited to their needs.
Some forms of Clinical Data
• Numerical Measurements
– Lab data
– Bedside measurements

DBA 1757
– Home instrumentation
NOTES • Recorded signals (e.g. ECG, EEG, EMG)
• Images (X-ray, MRI, CAT, Ultrasound, Pathology,…)
• Genes (SNPs, expression arrays, pedigrees, …)
• Coded / discrete data
– Family history
– Patient’s medical history
– Current complaint
• Symptoms (patient)
• Signs (doc)
– Physical examination
– Medications
• Narrative text
– Doctor’s, nurse’s notes
– Discharge summaries
– Referring letters
The most widely recognized data classification scheme is :
• Top secret
• Secret
• Confidential
When a document, letter, memo, or other piece of information is created, the owner
assigns to it a classification level, which among other things, defines the security clearance
of individuals that can access that information.
Similarly, in business, organizations adopt data classification schemes to define the
levels of confidentiality that are required for each piece of information created or maintained
by the organization. A corporate data classification scheme might comprise information
classifications such as:
• Company confidential
• Private
• Sensitive
• Public
Such a scheme greatly facilitates data security, because it instantly identifies and
communicates the level of protection required for any piece of data as well as the audience
that may view it. For example, a document that is tagged as “company confidential” is
easily recognized as not to be released outside of the company. Further, it limits those who
may access the information to a defined group.
A good data classification scheme also includes a time-element, to allow a piece of
information to change its status on a certain date. An example would be a public company’s
earnings announcement, which might be company confidential until the date of the earnings
announcement, at which time it becomes “public.”

There are many other attributes to data classification schemes, but these few points
are sufficient to establish why data classification is fundamental to information security. NOTES
Without a data classification scheme, an organization treats all information the same. This
increases the probability that sensitive data will not have adequate security controls,
increasing the risk of sensitive data being compromised. It also means that less sensitive
data will have more security controls than necessary, leading to unnecessary restrictions
and loss of efficiency for operational personnel.
Time Series - Data, Building time series of key data collections is a priority. Time
series are important because they enable users to track changes in health and related
social indicators over time.
Wherever possible, common classifications and recodes are used for the same data
variables in different data collections. For example, someone looking at the number of
people killed or injured in gun incidents may need to look at both ‘Mortality’ and ‘Hospital
Separations’ collections, perhaps along with background socio-economic data like socio-
economic status and income distribution in the area of residence.
3. 4.4.(ii).Metadata and Data Quality
Any Information System will have an extensive capability to store unlimited metadata
- for all elements in the system. The Information System should also have the capacity to
activate ‘triggers’ in specific cases to make users aware of specific information warnings,
or caveats about certain datasets, data elements, calculations or certain breakdowns of
particular datasets so that users are fully informed about caveats or concerns associated
with the use of that data.
The data collections undergo continuous quality improvement processes through close
collaboration with the Data Custodians, as well as through working groups to ensure
compliance with the most current data publication and release standards.
To design a table you must select:
• a dataset
• a row variable
• a column variable
• data items to appear in the table
• limits (optional)
When you select categories for your row, column and limits, different classifications
can sometimes be selected.
For example the category (or field) you select for your row may be ‘Area’. Once you
select this category you will have the choice of selecting one of many classifications.
For ‘Area’, most of the classifications are internationally accepted standard
classifications. If there are no standard classifications for the data, apply relevant

DBA 1757
classifications found in the hospital / medical literature to group the data. This gives the user
NOTES greater flexibility in data analysis.
Example
The category cigarette smoking-related diagnosis in the data collection ‘Hospital
Separations’, classifies diagnosis into 4 groups:
• diagnoses mainly due to smoking
• diagnoses partly due to smoking
• diagnoses with a component due to smoking
• non-smoking related diagnosis.
For this category there are no accepted standard classification so the developers can
choose a classification based on some parameters.
Classifications must be capable of coding all responses in an intelligible, ordered manner
while also satisfying the changing environment they represent and the needs of the users of
output data.
Some common classifications are

• Area Classification
• Cause of Death Classification
• Diagnosis Classification
• Principal Procedure Classifications
• Birthplace Classification
3. 4.4.(iii). Web - DBMS
A web dbms screen is shown below.

QUESTIONS:
NOTES
3.4.4.(a).Explain the types of Healthcare data.
3.4.4.(b). Explain Classification Systems.
3.4.4.(c).Explain Meta data and quality.
SUMMARY
You have learned the concept of Data warehousing and Data mining in detail. Also
you have understood the Data Mining Tools .You
Exercises
3.4.4.(I).Find out the types of Healthcare data in a multispecialty hospital.
3.4.4.(I).Browse the net and obtain the various data mining tools applicable to
Healthcare information system.

DBA 1757
NOTES

NOTES
UNIT IV
INFORMATION MANAGEMENT
CHAPTER 1
4.1 INFORMATION MANAGEMENT
4.1.1. Introduction
For the physician, a complete hospital information system replaces all paper based
routines and archives for patient administration. Medical records are required for managing
patients in a hospital. These cover patient administration, patient medical records, clinical
documentation, clinical data repository, order communi-cation and results reporting,
electronic medication admi-nistration record, emergency department records etc.. These
manage all types of elec-tronic information per patient (text, sound, images, video).
A core system may also include user administration, a register of workstations, access
authorization and functions for sys-tem monitoring. The structure of this information model
is based on the requirement that, response times in the system must be independent from
the number of patients and that the system must be able to handle patients’ data in large
volume.
Also laboratory testing is an increasingly important tool for diagnosis and treatment.
All test results are stored real-time directly from instrument to database and all controls are
handled in one place with a powerful solution for the central laboratory to manage several
satellite laboratories working towards the same database. The system should have integrated
quality control features, advanced reply functionality, configurable methods and automated
scheduling. Of course, the system handles electronic requisitions and replies with numerous
integration features towards primary healthcare systems and hospital information systems.
4.1.2. LEARNING OBJECTIVES

This unit gives you a fair idea about
9 The health care information systems,
9 Functions , types of administrative and clinical information system
9 Various aspects of a computerized hospital information system,
9 Its need for in hospitals.

DBA 1757
9 Also the various information management regulations, laws and standards
NOTES prevailing,
9 Legal and security aspects of healthcare information etc..
4.1.3. Types Of Administrative And Clinical Information System
4. 1.3. Conceptual framework for health care system
Source: AIHW 2006
4.1.4. Main Features And Functionalities
4.1.4.(i). Common features in an administrative and clinical information system :

a. Admittance and Discharge of patient : This is a fea-ture for administration of
admission and discharge of patients, as well as leave of absence for long term
pa-tients and transfer of patients between wards/depart-ments within the hospital.
b. Patient registry : When a patient is admitted to the hospital, either as a part of
the referral process or as an emergency visit, all relevant patient data and
demo-graphics will be recorded into the system.
c. Financial/billing : Any entry resulting in a financial transaction will be documented
as a part of the patient’s complete medical record.
d. Resource allocation : The different resources at any ward (staff and staff
categories, teams, rooms, beds, etc) are managed in this feature. This is
administrated in a sophisticated user configurable calendar with dif-ferent
scheduling options. It is possible to configure “groups” of resources, or “teams”
that can consist of different physicians, support staff, treatment rooms and
equipment.

e. Patient activity : All scheduled activities of a patient are managed in this special
feature. When a specific activity is decided, this is logged as a “new item” and will NOTES
be available from the patient’s medical record, re-gardless of which department/
ward that scheduled the specific activity.
f. Emergency ward : There is a special feature for ma-naging the flow of patients
at an emergency ward. In this feature, the user will be able to identify all the
pa-tients at the ward, patient flow, location of the patient, responsible care giver
and scheduled activities for the individual patient.
g. Chronological case record : The medical record is pre-sented in chronological
order, and a list of all available documents is always presented on the screen
enhancing user efficiency and accessibility to other parts of the patient file. Another
tool for optimizing the work with the patient and make the documentation more
ef-ficient is to use the feature of digital dictation.
h. Prescription : It is possible to define several types of prescriptions in an IS.
These could be normal prescriptions and special prescription for restricted drugs.
When prescribing a medication this can be done by selecting from a list of previous
prescriptions on a specific patient, or selecting from a list of medica-tions in the
pharmacy’s database.
i. Vital signs and other measurements : This module is generally a system for
handling all the different mea-surements of a patient. This is defined as information
that can be recorded as a numeric value, either from manually entering the
information or selecting from a list of pre-defined values. The measurements can
be presented as tables, graphs or as documents.
j. Centralized care plan : This is a feature to manage the continuum of care between
secondary care and the primary care for patients who are discharged from a
hospital and transferred back to the primary care for follow up.
k. Electronic laboratory ordering and results : Electronic referrals and
labo-ratory remittance to medical laboratory, reduces the work load at the
laboratory and makes the referrals more efficient to execute and easier to keep
track of.
l. Electronic referrals and discharge letters : It is pos-sible to electronically
transfer data to other institu-tions, for example a healthcare center in the same
re-gion. This could either be referrals from primary- to secondary care or discharge
notes from the hospital. This can be done either by using Internet, Medical
Interchange, other EDI systems and even by the traditional referrals on plain
paper.
m. Instrument communication platform : The instru-ment communication platform
(ICOM) provides interfaces to most instruments on the market using IP-
communication, bidirectional RS232 or file com-munication. ICOM runs on one
or several dedicated PCs, or as a service on the normal workstations at the

DBA 1757
laboratory. New instruments may be hooked up to the system during production
NOTES without turning off the communication for the other instruments. Configura-tions
such as communication protocol, flag handling with associated comments and
instrument location can be done with a user friendly administration pro-gram.
System administrators may also start, stop and monitor instruments both internally
and at externally connected labs.
n. Pre-analysis : The pre-analysis functions provide sup-port for sample arrival
registration, order registration, forwarding functions to other laboratories, labeling
functions, etc.
o. Analytical production : The analytical production mo-dules provides rich
functionality to create work lists, medical assessments and diagnosis. For
complicated replies, the IS provides word processing capa-bility for the laboratory
doctor or assistant. It also supports electronic dictation devices such as Speech
Mike. For diagnostic purposes it is im-portant to have access to as much
information about the patient as possible and keeps a com-plete track of patient
samples and diagnostic informa-tion, and this is available at all times. A patient
can be identified via personal or social security number, name or from a previous
sample. These and other frequently used routines are easily accessible from
anywhere in the system.
p. Batch processing : The batch processing functions pro-vides background
process programs and time schedu-led programs including transfer of electronic
results, mailing of paper results, etc.
q. Post-production and financial/billing : The cost of each sample is calculated
automatically ac-cording to user-defined rules. Credits and changes are handled
by the system. Economy reports and customer invoicing details are also available.
r. Electronic ordering and results : con-tains functionality for receiving electronic
requisitions and sending electronic replies. Other features are advanced reply
functionality, configurable methods, scheduling and timing. A standard interface is
used for input and output of data. Often laboratory personnel wish to be notified
when a new sample from a patient arrives.
s. Statistics and reporting : Many standardized reports and statistical routines,
in-cluding a built-in report generator for producing your own statistics, and extracts
raw data for later analysis and research using your favorite statistical package.
Support for various third party reporting tools including Crystal Reports. Re-ports
can be created in many formats and styles, and be made available via e-mail or
the Internet. Reports to national health programs can also be automatically
generated.
t. Quality assurance : The integrated daily and long-term quality control, where
results that fall outside of defined control limits and rules are automa-tically flagged
to the user.

u. Multi-site laboratory clusters : A common implemen-tation have several

laboratories working towards the same database, giving the possi-bility to share NOTES
information. Registration is only made once and the samples are forwarded to the
appropriate destination. Built-in decision support simplifies the ar-rival of samples
at the laboratory. However, to simplify matters, each laboratory views only the
data necessary for their own needs.
v. Point-of-Care testing – POCT : Availability to integrate direc-tly with EMR

systems to provide a structured environ-ment for point-of-care testing, including
instrument connections and data gathering, analysis order regist-ration, registration
of test results and control data and quality assurance including monitoring and
follow-up statistics.
4.1.4.(ii). Records and features
The classification reveals the group of functions pertaining to different types of users
of this information system. Further each and every users of the system have their own
functional requirements and presentations of their task. Listed below are some of the users
and features in a medical information system.
Individual Users of Patient
• Providers
• Chaplains
• Dental hygienists
• Dentists
• Dietitians
• Lab technicians
• Nurses
• Occupational therapists
• Optometrists
• Pharmacists
• Physical therapists
• Physicians
• Physician assistants
• Podiatrists
• Psychologists
• Radiology technologists
• Respiratory therapists
• Social workers
• Management
• Administrators
• Financial managers and accountants

DBA 1757
• Quality assurance managers
NOTES • Records professionals
• Risk managers
• Unit clerks
• Utilization review managers
• Reimbursement
• Benefit managers
• Insurers
• Other
• Accreditors
• Gov’t policymakers, legislators
• Lawyers
• Health care researchers, clinical
Investigators
• Health Sciences journalists and editors
• Patients, families
Secondary Uses of Patient Record
• Education
• Document health care professional experience
• Prepare conferences and presentations
• Teach students
• Regulation
• Evidence in litigation
• Foster postmarketing surveillance
• Assess compliance with standards
• Accredit professionals and hospitals
• Compare health care organizations
• Policy
• Allocate resources
• Conduct strategic planning
• Monitor public health
• Research
• Develop new products
• Conduct clinical research
• Assess technology

• Study patient outcomes

• Study effectiveness and cost effectiveness of care NOTES
• Identify populations at risk
• Develop registries and databases
• Assess cost-effectiveness of record systems
• Industry
• Conduct R&D
• Plan marketing strategy
User Requirements
• Record Content
• Uniform core data elements
• Standardized coding systems and formats
• Common data dictionary
• Information on outcomes of care and functional status
• Record Format
• “Front-page” problem list
• Ability to “flip through” the record
• Integrated among disciplines and sites of care
• System Performance
• Rapid retrieval
• 24/7
• Available at convenient places
• Easy data input
• Linkages
• To other info systems (e.g., radiology, lab)
• Transferability of information among specialties and sites
• With relevant literature
• Other registries and institutional databases
• To records of other family members
• E-billing
• Training and Implementation
• Minimal training required
• Graduated implementations
• Intelligence
• Decision support
• Clinician reminders
• “Alarm” systems, customized

DBA 1757
• Reporting
NOTES
• “Derived documents”, e.g., insurance forms
• Easily customized output, User Interface
• Standard clinical reports, e.g., discharge summary
• Custom and ad hoc reports
• Trend reports and graphics
• Control and Access
• Easy patient access
• Safeguards of confidentiality
4.1.5. Functional Capabilities Of Computerized Hospital Information System
The purpose of a hospital information system (HIS) is to manage the information that
health professionals need to perform their jobs effectively and efficiently. The Information
models may be based on the requirements of a typical computerized hospital environment
may be as given below
• Operational Requirements
• up-to-date factual information
• necessary for day to day tasks
• Planning requirements
• short- and long-term decisions about patient care
• decisions about hospital management
• Documentation Requirements
• the maintenance of records
• accreditation
• legal record
It costs a lot of money to deal with the information in a hospital if we adopt a general
classification of the model
The Friedman and Martin functional model for an HIS shows the functional listing as
• Core Systems
• patient scheduling
• admission
• discharge
• admission-discharge-transfer (ADT)
• Business and Financial Systems
• payroll
• accounts receivable

• Communications and Networking Systems

• integration of all parts of the HIS NOTES
• order entry & results reporting
• Departmental-Management Systems
• the needs of individual departments can be met
• those subsystems can be useful in a macro-system
• Medical-Documentation Systems
• collecting, organizing, storing, and presenting
• Quality Assurance (QA)
• Medical Support Systems
• assistance in interpreting data
• issue alerts, provide advice
It can be useful to integrate the clinical and the administrative information into the
same information system. This can create a “rich database for decision making.” Also
there are some alternative architectures for the Hospital Information Systems such as
• Central Systems
• total or holistic system
• one main computer handling all the information
• many terminals and printers for information exchange
• Transaction Management Information System
• Problems:
• very difficult to backup
• hard to keep up to date technology
• all or nothing effect
• Modular Systems
• distinct software modules carry out specific tasks
• “plugging in” new task performance
• A ‘HELP’ to provide assistance in carrying out specific tasks
• Problems:
“plugging in” never works very well
• Distributed Systems
• LAN structure
• independent computers tailored for specific uses
• autonomous
• computers with shared data
• can connect multiple LANs
• Problem Oriented

DBA 1757
Trends in HIS development:
NOTES • Local-area communication networks
• LANs are cheaper and more effective
• Workstations and personal computers
• On a LAN you need some computers
• Bedside terminals
• Have not caught on yet due to cost
• Linkages between hospitals and physicians
• as automation occurs natural links occur
spital-based Care Quality Information Collection and Reporting Flow
Hospital-based Care Quality Information Collection and Reporting Flow

1. Defined quality measurement specifications to be reported are sent to hospitals.
2. Notice is given to clinicians to support clinical decisions and augment recorded
data.
3. Longitudinal health information held in associated repositories is forwarded.
4. Hospital quality data is sent either via an intermediate entity or point-to-point for
onward transmission to the Multi-Hospital measurement and reporting entity
(Patient-level –identifiable).
5. Preview report is sent directly for validation and/or correction (aggregated hospital
– level data).
6. Corrected quality information is sent directly to the multi-hospital feedback and
reporting entity (patient-level-identifiable).

7. Corrected reports are sent for validation and/or correction (aggregate hospital-
level data). NOTES
8. Claims data is collected from payers (patient-level-identifiable)
9. Distributed data is available to users (aggregate hospital level data)
Clinician Quality Information Collection and Reporting Flow

1. Defined quality measurement specifications to be reported are sent to clinicians.
2. Notice is given to clinicians to support clinical decisions and augment recorded
data.
3. Longitudinal health information held in associated repositories is forwarded (patient-
level-identifiable)
4. Clinician quality data is sent either via an intermediate entity or point-to-point for
onward transmission to the multi-entity feedback and reporting entity (patient-
level-identifiable)
5. Preview report is sent directly for validation and/or correction (aggregate hospital
level data)
6. Corrected quality information is sent directly to the multi-entity feedback and
reporting entity (patient-level-identifiable)
7. Corrected reports are sent for validation and/or correction (aggregate clinical-
level data)
8. Claims data is collected from payers (patient-level-identifiable)
9. Distributed data is available to users (aggregate clinical-level data)
Clinician Quality Information Collection and Reporting Flow

DBA 1757
4.1.6. Need for Computerization in Hospitals

NOTES
Nowadays, it is hard to imagine health care without information communication
technology (ICT). The quality of information processing is an important factor for the
success of health care institutions
a) Good information systems can support clinical workflow in various ways and thus,
contribute to a better patient care
b) On the other side, insufficiently designed information systems can have negative
effects on efficiency and quality of patient care
c) Information processing in health care not only depends on computer-based tools,
but also still relies to a large part on paper-based tools such as the paper-based
patient record. Therefore, we understand hospital information systems (HIS) as
the complete information processing and information storing subsystem of a hospital,
including both computer-based and paper-based information processing tools
d) Systematic management of information systems is essential, and the major tasks of
information management comprise planning, directing and monitoring the hospital
information system. While planning and directing of information systems are well
understood and supported, monitoring of information systems is often seen as
insufficient. Monitoring means to regularly analyze and supervise the quality of the
HIS in order to promptly recognize weaknesses (such as technical problems,
problems with data quality, information losses, low user acceptance, etc.).
In most hospitals, regular HIS monitoring activities using a quantified assessment of

HIS quality are missing. One reason could be that standardized methods and tools for
monitoring are missing. For example, hospital quality programme comprise few aspects of
HIS quality. Other approaches such as software ergonomic standards (e.g. ISO 9241 [8])
focus only on computer-based tools and ignore the significance of paper-based tools.
Projects developing requirement indexes such as Ref. [9] describe HIS functionality in a
rather comprehensive form, but do not support the evaluation of quality, and also do not
consider the effects of HIS on working processes.
Every health centre individually functions as an organization, having its own branch of
functions. If you consider an information system for hospitals, the number of information
systems to be designed developed and implemented become countless. To mention a few:
a. Ambulatory Information System
b. Admissions and Discharge
c. Accounting and Financial Information System
d. House Keeping System
e. Hospital HR System
f. Laboratory Information System
g. Medical Diagnosis and Treatment System

h. Nursing System
i. Pharmaceutical System NOTES
j. Patient Health Information System
k. Surgical information System etc..
For each of the system we need to document defining the following variables
• Data Set Name:
• Location/Owner of Data Set
• Purpose for Which Data Collected
• Restrictions on Data Use
• Data Request(s)
• Description:
o Method of Data Collection
o Percent Return
o Frequency of Updating
o Years of Data
• Types of Data Output Available
• Cost for Data Output
• Standard Reports Generated
• Data Elements
Here is sample flow chart of the diagnosis flow diagram helping the obstetric patients

DBA 1757
Where Are Hospitals now in EHR adoption?

NOTES
Hospitals have a long road ahead to adoption of electronic health records. The EHR
functions in which the greatest number of hospitals reported significant progress are:
• Order entry
• Results management
• Electronic health information / data capture
• Administrative processes
The most significant barriers to EHR adoption are:
• Lack of national information standards and code sets

• Lack of available funding
• Concern about physician usage
• Lack of interoperability
4.1.7. Healthcare Information Regulations, Laws and Standards
Most of us feel that our health and medical information is private and should be
protected, and we want to know who has this information. Health care information regulations
• Gives you rights over your health information
• Sets rules and limits on who can look at and receive your health information The
law, to whom it applies ?
• Most doctors, nurses, pharmacies, hospitals, clinics, nursing homes, and many
other health care providers
• Health insurance companies, most employer group / family health plans
• Certain organizations that pay for health care, such as Medicare and Medical aid.
What is the information which is protected?

• Information your doctors, nurses, and other health care providers put in your medical
record
• Conversations your doctor has about your care or treatment with nurses and others
• Information about you in your health insurer’s computer system
• Billing information about you at your clinic
• Most other health information about you held by those who must follow this law
Who are the people who are authorized to look into a person’s health record
To make sure that your information is protected in a way that does not interfere with
your health care, your information can be used and shared
• For your treatment and care coordination
• To pay doctors and hospitals for your health care and help run their businesses
• With your family, relatives, friends or others you identify who are involved with
your health care or your health care bills, unless you object

• To make sure doctors give good care and nursing homes are clean and safe
• To protect the public’s health, such as by reporting when the flu is in your area NOTES
• To make required reports to the police, such as reporting gunshot wounds
Your health information cannot be used or shared without your written permission
unless this law allows it. For example, without your authorization, your provider
generally cannot
• Give your information to your employer
• Use or share your information for marketing or advertising purposes
• Share private notes about your mental health counseling sessions
The privacy rules
The Privacy Rule protects a subset of individually identifiable health information, known
as Protected Health Information or PHI, that is held or maintained by covered entities or
their business associates acting for the covered entity.
The Privacy Rule does not protect individually identifiable health information that is
held or maintained by entities other than covered entities or business associates that create,
use, or receive such information on behalf of the covered entity.
To understand the possible impact of the Privacy Rule on their work, you will need to
understand what individually identifiable health information is and is not protected under
the Rule. With certain exceptions, the Privacy Rule protects a certain type of individually
identifiable health information, created or maintained by covered entities and their business
associates acting for the covered entity. This information is known as “protected health
information” or PHI.
The Privacy Rule defines PHI as individually identifiable health information, held or
maintained by a covered entity or its business associates acting for the covered entity that
is transmitted or maintained in any form or medium. This includes identifiable demographic
and other information relating to the past, present, or future physical or mental health or
condition of an individual, or the provision or payment of health care to an individual that is
created or received by a health care provider, health plan, employer, or health care
clearinghouse. For purposes of the Privacy Rule, genetic information is considered to be
health information.
The Privacy Rule allows a covered entity to de-identify data that could be used to
identify the individual or the individual’s relatives, employers, or household members; these
elements are enumerated in the Privacy Rule. The covered entity also must have no actual
knowledge that the remaining information could be used alone or in combination with other
information to identify the individual who is the subject of the information.

DBA 1757
Protected Health Information. The Privacy Rule protects all “individually

NOTES identifiable health information” held or transmitted by a covered entity or its business
associate, in any form or media, whether electronic, paper, or oral. The Privacy Rule calls
this information “protected health information (PHI).”
“Individually identifiable health information” is information, including demographic

data, that relates to
• the individual’s past, present or future physical or mental health or condition,

• the provision of health care to the individual, or
• the past, present, or future payment for the provision of health care to the individual,
and that identifies the individual or for which there is a reasonable basis to believe can
be used to identify the individual. Individually identifiable health information includes many
common identifiers (e.g., name, address, birth date, Social Security Number).
The Privacy Rule excludes from protected health information employment records
that a covered entity maintains in its capacity as an employer and education and certain
other records subject to, or defined
HIPAA standards apply only to

• Health care providers who transmit any health information electronically in
connection with certain transactions
• Health plans
• Health care clearinghouses
A health care provider is –

• Any person or organization who furnishes, bills, or is paid for health care in the
normal course of business
Health care providers are covered only if they transmit health information electronically in
connection with a transaction covered by the HIPAA Transaction Rule
• Directly or through a business associate
HIPAA Transactions Rule Standards

1. Health care claims or equivalent encounter information
2. Health care payment and remittance advice
3. Coordination of benefits
4. Health care claim status
5. Enrollment or dis-enrollment in a health plan
6. Eligibility for a health plan
7. Health plan premium payments
8. Referral certification and authorization

What Is A Health Plan?

NOTES
Any individual or group plan (or combination) that provides, or pays for the cost, of medical
care. Examples include:
• Health insurance issuers
• HMOs
• Group Health Plans
• Medicare, Parts A and B
• Medicare + Choice
• Medicaid
• All health plans are covered
• Entities that are not considered health plans include
o Employer plans with fewer than 50 participants and which are self-administered
o Excepted Benefit Plans
o Certain government funded programs
• Under ERISA, a group health plan is a separate legal entity from the employer/
plan sponsor
• The Privacy Rule does not cover employers or plan sponsors
What Is A Health Care Clearinghouse?
How does Rule Apply?

• Translates data content or format for another entity from non-standard to standard
or vice versa
• Limitation on Applicability of Privacy Rule
Who Is A Business Associate?
A person who performs a function or activity on behalf of, or provides services to, a
Covered Entity that involves Individually Identifiable Health Information
• Is not a workforce member
• Covered Entity can be a Business Associate
• Two Covered Entities –each performing functions on its own behalf
o Provider gives PHI to payer for payment
o Hospital and physician treating patients at hospital
• Persons or organizations where access to protected health information is not
necessary to do their job
o Janitors, electricians, copy machine repair persons
Business Associate Exceptions

• Disclosures to a provider for treatment to an individual
• Disclosures by a group health plan to plan sponsor if for plan administration
• Uses or disclosures by a government health plan (e.g., Medicare) to another agency
(e.g., SSA) for eligibility or enrollment determinations if authorized by law

DBA 1757
ORGANIZATIONAL ISSUES
NOTES
Hybrid Entities
• Covered Entity that does both covered and non-covered functions
• Option to restrict the application of the Privacy Rule to certain parts of its
organization
• By designating health care components (HCC)
• This designation will make the Covered Entity a “Hybrid Entity” under the Rule
Affiliated Covered Entities

• Legally separate Covered Entities
• Under common ownership or control
• Option to be treated as a single legal entity
• By choosing to designate
• This designation will make the Covered Entity an “Affiliated Covered Entity” under
the Rule
• May be able to share information in a way that would otherwise be impermissible
(sharing becomes a “use” not a “disclosure”).
• May minimize administrative burdens
• BUT, each is separately subject to liability for enforcement actions, and could be
cumbersome to devise and comply with uniform set of policies, and/or one notice
Some common standards

NOTES
4.1.8. Legal Aspects of Managing Healthcare Information
Computerization of medical devices is a natural consequence of the need to rapidly

acquire, process, analyze and present ever-increasing amounts of data. Interconnection of
those medical devices facilitates a direct (and therefore rapid and more accurate) exchange
of data between disparate diagnostic, therapeutic and health information systems.

DBA 1757
While computerization and interconnection of medical devices and systems represents

NOTES a generally positive development, these trends are not without their stumbling blocks.
Principle among the obstacles en-countered is the diversity of technologies, the paucity of
technical standards, and the industry’s failure to agree to the adoption of those technical
standards that do exist. The consequence is a technical “Tower of Babel” where diverse
devices and systems from a variety of manufacturers are unable to effectively exchange
critical health information because they format that information in different ways. When
data cannot be ex-changed directly, humans must “translate” outputs from one set of devices
and systems and manually input that data into another set of devices and systems – an
inherently inefficient and error-prone process.
Recognizing both these trends and the corresponding obstacles, in the west, the
Radiological Society of North America (RSNA) and the Healthcare Information and
Management Systems Society (HIMSS) launched an initiative called Integrating the
Healthcare Enterprise (IHE) in 1999. IHE brought together medical professionals and
the healthcare information and imaging systems industry “to agree upon, document and
demonstrate standards-based methods of sharing information in support of optimal patient
care.”
The IHE initiative is defining integration profiles for variety of systems. These
integration profiles describe important, common, core processes (e.g. scheduled workflow,
image presentation, information access, record retrieval, reporting, charge posting) in the
clinical disciplines (e.g., radiology, laboratory, cardiology). IHE also adopts existing standards
(e.g., DICOM, HL7) rather than attempting to create its own. By defining integration
profiles and adopting existing standards, IHE is establishing guidelines for medical technology
manufacturers to follow to insure their systems will interface and work with components
produced by other manufacturers. So far, IHE has achieved considerable success in the
area of medical imaging systems. Each year, the main sponsors of IHE host a “connect-
athon” (held in conjunction with the annual RSNA conference in Chicago) where
manufacturers bring their products and demonstrate interoperability of their products with
those from other manufacturers. Using the IHE’s integration profiles and adopted standards,
participants at the connect-athons have demonstrated they can successfully conduct a
variety of processes including ordering tests, cataloging orders, conducting tests, viewing
test results (including images), recording analyses, and generating billing information with
system components supplied by a diverse group of manufacturers.
After successful efforts in medical imaging, IHE is attempting to broaden its scope
into clinical laboratory, cardiology and other areas that would benefit from the effective
integration of biomedical and information technology systems. Key to the success of IHE’s
initial efforts in medical imaging was the sponsorship and strong support of HIMSS, RSNA
and their constituents (e.g., manufacturers and providers). Likewise, achieving similar
success in the development of interoperable technologies for other clinical disciplines
depends on the sponsorship of and support of key organizations.
The American College of Cardiology (ACC) and NCCLS (formerly the National
Committee for Clinical Laboratory Standards) have joined with the IHE initiative to develop NOTES
integration profiles for cardiology and laboratory systems. Most recently, the American
College of Clinical Engineering (ACCE) has also joined the IHE initiative to work on the
development of integration profiles and the adoption of standards for general patient care
devices.
It is vitally important that we, as clinical engineers, support IHE efforts. Effectively
implemented, medical technology can play a major role in improving the quality, safety,
timeliness, and cost-effectiveness of health-care. That role will only be fully realized when
the technology we employ is truly interoperable and interoperability is achievable only if a
broad based initiative like IHE succeeds. Clinical engineers must participate in the process,
joining with ACCE and other IHE sponsors, encouraging other stakeholders in their
institutions to support the initiative, and pressuring manufacturers to provide products that
have demonstrated IHE interoperability. The future of the “digital hospital” or healthcare
provider depends on our active involvement.
Common standards ruling the healthcare information system are as follows

HL7, v2.x
– Messaging standard for communicating clinical data
– Used in reporting labs, tying together departmental systems, (experiments in) data
integration
– No commitment to storage structures
– HL7, v3
– Clinical Document Architecture, Reference Implementation Model
– Act (PatientEncounter, ControlAct, Supply, Diet, WorkingList, Procedure,
Observation, DeviceTask, SubstanceAdministration, FinancialContract, Account,
FinancialTransaction, InvoiceElement)
RIM diagrams
DICOM – Images
Coding Standards for clinical content
ANSI X.12 messages for EDI
Medicare (CMS) forms
o Patient care reimbursement (various settings)
o Institutional status, finances, regulation compliance
o CCR: Continuity of Care Record (ASTM & Mass Med)
o “organize and make transportable a set of basic patient information consisting of
the most relevant and timely facts about a patient’s condition”
o patient and provider information

DBA 1757
o insurance information
NOTES o patient’s health status (e.g., allergies, medications, vital signs, diagnoses, recent
procedures)
o recent care provided, as well as recommendations for future care (care plan)
o the reason for referral or transfer
4.1.9. Security of Healthcare Information System
The Information system with all the mentioned benefits always have risk associated
to it. The risk being the information system threats created from inside and outside the
organization or the users and beneficiaries of the information.
The Health Information Management profession has developed a Code of Ethics to

define the principles governing the professional conduct of its members / users.
Code of Ethics:
To safeguard the criticality, the members / users of the Health Information Management
Association shall:
1. Respect the rights and dignity of all individuals.
2. Show courtesy to and respect all professional colleagues.
3. Undertake their professional duties in an efficient, proper and responsible manner.
4. Not engage in dishonesty, fraud, deceit, misrepresentation or other forms of illegal
conduct that adversely reflect on the profession or the individual’s fitness for
membership in the profession.
5. Preserve and protect the integrity of health records in their control and the
information they contain.
6. Ensure, within the scope of their responsibility, that all patient identifiable information
will be kept confidential. Ensure the release of information is in accordance with
current laws and regulations and institutional policies. Preserve the confidential
nature of professional findings and recommendations made by committees of health
institutions unless compelled otherwise by legal means. Strive to ensure that the
patient’s right to confidentiality and the public’s right to know is ethically and legally
correct.
7. Report to the appropriate authorities any evidence of conduct or practice that
indicates possible violation of established rules and regulations of the employer or
of professional practice.
8. Set and accept an appropriate and lawful fee for services rendered in their official
capacity.
9. Not assume the right to make determinations in professional areas outside the
scope of their assigned responsibilities and knowledge.
10. State truthfully and accurately their professional credentials, education and
experience.
11. Discharge honourably the responsibilities of any national or state association position
and preserve the confidentiality of any privileged information obtained whilst acting
in an official capacity.

12. Seek to maintain and improve professional knowledge and competence by

undertaking appropriate study and participating in continuing education activities. NOTES
13. Contribute to the planning and development of services which enable individuals
within the community to achieve optimum health.
14. Strive at all times to promote the objectives of the Health Information Management
Association of Australia Limited.
QUESTIONS
4.1.(a).Identify the different types of administrative and clinical information System.
4.1.(b). Discuss the features of an Administrative and Clinical Information System.
4.1.(c).Discuss the Functional Capabilities Of Computerized Hospital Information
System .
4.1.(d).Is there any standard specification to develop Healthcare Information System?
If so elaborate.
4.1.(e).Discuss the Regulations and Laws related to Healthcare Information System.
4.1.(f).Discuss the Code of Ethics in connection with Security of healthcare information
system.
4.1.(g).Why hospitals are to be computerized?
Exercise
*Meet the Administrative Officer of a Multispecialty Hospital and collect
information about the Regulations, Laws and Standards which they are
following in their Healthcare Information System.
Summary
You might be familiar with types of administrative and clinical information system. You
would be clear with the Regulations, Laws and Standards which are to be followed when
developing a Healthcare Information System and also the Code of Ethics.

DBA 1757
NOTES

NOTES
UNIT V
DELIVERY NETWORK
CHAPTER 1
5.1 HEALTH CARE INDUSTRY: CHALLENGES AND IMPLICATIONS
5.1.1 Introduction
Macro trends in the healthcare industry such as improving patient safety, securing
access to clinical records, reducing healthcare fraud, eliminating wasted work and improving
the overall patient experience are focusing attention on finding better and more reliable
means for human identification. These trends are forcing healthcare organizations to explore
alternative technologies that will help them meet the ever-increasing demand for robust,
cost effective and accurate identity management.
In today’s healthcare settings, the need for fast and accurate patient identification has
never been more important. In fact, healthcare CEO’s rated this issue as one of the most
essential factors affecting proper delivery of clinical services.
After reading this chapter, you should be able to understand
• The Challenges in healthcare delivery

• Managerial Implications on healthcare delivery
• Advance Health Care Using Computers
• The Future Of Integrated Healthcare IT
• To know about the introduction of Smart cards
• The types of delivery models
5.1.3. The Challenges In Health Care Delivery
The challenges of correctly identifying patients are both varied and complex. A single
average-sized hospital can often be tasked with maintaining hundreds of disparate patient
databases; a larger healthcare system that has grown through acquisition may find itself

DBA 1757
supporting multiple operating platforms that do not communicate between hospitals or

NOTES even amongst themselves within a single facility system. In an effort to solve these issues,
some healthcare organizations have turned to complete overhauls of their database platforms
by implementing Enterprise Master Patient Index (EMPI) systems. These efforts require
enormous resources in both organizational focus and capital expenditure. A typical EMPI
installation may take years to complete and cost tens of millions of dollars.
Whether a healthcare organization elects to implement an EMPI system or not, it still

faces a fundamental problem because patient identification today is largely dependent upon
demographics. Because these demographic factors are not static (can vary over time),
demographic based patient searches can create duplicate records for a single patient or
often result in the misidentification of the patient which leads to improper or incomplete
medical care. According to a study by Madison Information Technologies, Inc., single
facility hospitals have duplication error rates that average 9% - 11%, and have reached as
high as 20%, while multi-facility hospitals have error rates that have reached levels as high
as 30%
The stakes are high. There are numerous benefits that can be realized by advancing
patient identification techniques:
• Improved Patient Safety
• Reduced Operating Costs
• Improved Patient Experience
• Process Efficiencies
5.1.3. (i)Identification of Healthcare Professionals
Equally as important as identifying patients is identifying healthcare workers. As

hospitals and other clinical settings have migrated to a dependency upon computerized
patient care, the need to digitally identify healthcare professionals has become paramount.
The use of a physical signature to authorize or signify responsibility for delivery of healthcare
services has mostly given way to a point and click, or a password.
Accurately identifying the healthcare professional electronically presents a series of

new and unique challenges. The methods used for identification must be highly reliable, fast
and flexible in order to successfully operate across many varied healthcare locations and
conditions. Many healthcare providers are challenging the conventional approach of using
a simple password when logging onto a workstation as a means for positive identification.
This issue is vital for meeting the higher accuracy and security standard when processing
sensitive or high-risk electronic orders (i.e.: medications, emergency procedures and
releasing patient records).
This focus on improving the methods for digital identification of healthcare professionals
is based upon accomplishing the following:

• Reduction & Prevention of Fraud

• Regulatory Compliance NOTES
• Improved Work-Flow
Implementing information systems in healthcare organizations poses a series of

challenges. These include complexity, human acceptance of IT, data security, and data
quality and standards. In light of these challenges, some argue that no other industry
invests as little in IT as the healthcare industry. Most hospitals and physicians still rely on
outmoded paper records organized by visual color codes, alphabet and number.
5.1.3. (ii)Complexity.
Developing a comprehensive information system that supports Total Quality

Management can be very complex and expensive. For example, the computerization of
the paper-based patient records for the University of Texas M.D. Anderson Cancer Center
involved the integration of 115 computer networks. This is technologically complex, and
many healthcare organizations do not have the in-house managerial capability and knowledge
to implement IT successfully.
The ultimate success of quality initiatives lies in the ability to improve the core clinical
processes with respect to patient care.. Earlier efforts in IT, however, have been more
intent on merely replacing existing administrative transactions than on understanding the
comprehensive information needs of a healthcare institution. Simpson reports that although
99% of American hospitals use computerized financial systems, only 14% have point-of-
care documentation systems, and 9% have clinical data depositories. Another survey of
360 acute care hospitals found that only 9% of the hospitals had computerized all areas
and functions, and not a single hospital had integrated these separate computer systems
into a network. The current challenge is to use IT to help a healthcare institution achieve
clinical and wellness goals, rather than merely document the care for billing purposes.
5.1.3 .(iii)Human acceptance of IT.
Organizational culture or the human factor can prove to be a strong barrier to both IT
and TQM implementation. Inter-organizational settings, typical of today’s integrated health
networks, pose additional difficulties for implementing quality improvement Horizontal
information coordination across various organizations can provide a competitive advantage
in situations where integrated networks are becoming more prevalent
5.1.3. (iv)Data security.
Ensuring the integrity and confidentiality of patient-related data is a major requirement

of healthcare information networking strategies. The availability of easy and rapid electronic
transmission of patient information to various organizations at different locations increases
the risk of violating confidentiality. Because of convenience and efficiency, staff may forget

DBA 1757
to consider the privacy implications. Rather than improving healthcare quality, IT could
NOTES reduce patient satisfaction and the quality of care. Confidentiality is especially problematic
in the management of suspected child abuse cases, psychiatric cases and for patients with
AIDS.
5.1.3.(v) Data quality and standards.
Quality improvement data must be reliable and valid in order to measure performance
and change within a healthcare system or to make comparisons with other organizations..
Electronic sharing of information is difficult. In some hospitals a 24-hour stay is classified
as an inpatient episode while other hospitals classify it as outpatient care. There is still a
lack of agreement with respect to treatment codification schemes and medical textbook
headings.
The American National Standards Institute and the American Medical Informatics
Association, among others, are addressing data standardization issues in the U.S. In August
1996, the U.S. government enacted into law a process that will govern the adoption of
national standards for health-related electronic commerce. The law requires compliance
with national standards by the year 2000. It also requires a standard, unique health identifier
for each individual, employer, health plan and healthcare provider in the healthcare system.
5.1.4. Managerial Implications
To achieve success in TQM, healthcare managers must plan information systems

carefully and with a long-term view. In order to ensure that an information system supports
both the process of quality improvement and the measurement of outcomes, managers
should use the conceptual framework.
‘ Clinical information systems development and the integration of these systems with
administrative information systems are more complex tasks than the mere expansion of
business and financial systems. The following guidelines are intended to assist healthcare
managers obtain the optimum contribution of IT to quality management efforts.
5.1.4.(i) Leadership and involvement.
An IT plan developed to support a healthcare organization’s TQM strategy should

reflect top management’s leadership and enthusiasm for the concept. Managers should
also work to ensure the involvement of all parties who will be affected by the implementation
of the comprehensive IT plan. The plan should reflect a balanced perspective of all
stakeholders, administrative personnel, clinical personnel, patients, insurance companies,
the local community and the government. These different perspectives should be explicitly
stated in writing and evaluated as part of the planning process. Managers should specify
clearly the benefits that IT will provide to various organizational groups, and these benefits
must be marketed actively both internally and externally.

Studies have shown that for IT systems to support a quality strategy, employee
involvement is crucial. For example, end users should be involved in implementing the use NOTES
of computers for nursing diagnoses. Clinicians should be part of the process to develop
computerized patient records. If clinicians do not recognize the connection between IT
and the quality of patient care, they will not participate in the process. The administration’s
attitude should support the physicians and provide personal computer access at home, in
the office and in the physician’s lounge at the hospital. It is also helpful if a physician can
access and enter information at the nurses’ station without the intervention of a nurse or
unit secretary.
Computer-clinician interactions in the diagnosis and treatment processes need to be

flexible enough to permit an individual physician to maintain control and feel in charge.
Computer-clinician interactions must also be fast. In an increasingly competitive industry,
the views of the patient have become more significant. Yet, collecting data on quality
outcomes is particularly difficult when relying on patients.
5.1.4 .(ii)Goals and standards.
Management must establish organizational goals or standards for both the administrative
and clinical processes. Managers must begin with a focus on outcomes. The decision of
what outcomes to measure determines the type of data that need to be collected and
maintained
5.1.4. (iii) Achievement of goals and standards.
Managers should plan, coordinate and implement information technologies that can
improve quality and efficiency in all processes. For example, an organization should provide
on-line medical records and other clinical information at multiple sites, such as laboratory
results and imaging.
5.1.4.(iv) Data collection and maintenance.
Measures to evaluate the outcomes of the various processes must be developed.

These have implications for the type of data that need to be collected and the design of
databases and records. The issue of data quality is particularly crucial because the resulting
information is used to make vital decisions. Data entry of patient information must be free
of transcription errors. Data must be maintained in order to provide longitudinal performance
measures for the various clinical and administrative processes and develop a clear track
record against the quality standards that have been set.
If a quality improvement team uses poor data to report outcomes, this provides an
excuse for some personnel in the organization to criticize and remain peripheral to the
quality improvement process. This is another reason why involvement of all parties is crucial.
Clinicians must be involved in establishing the standards of practice, performance levels

DBA 1757
and types of data required in their particular areas of expertise. The system can then be
NOTES instructed to build an appropriate database that can be used to compare actual outcomes
with the standards.
Policies and guidelines concerning the confidentiality of patient information need to be

developed and enforced. There should be an effective supervisory and legal structure that
provides sanctions against detected abuse of information. Systems should be designed to
accommodate evolving policies and security management technologies. Access to records
can be restricted. Indeed, IT can provide more protection of patients’ privacy than can
paper documentation systems. Password and audit trails can protect patients. Deterrent
alerts, reminders and education of the computer users are also very effective in reinforcing
ethical behavior.
5.1.4.(v) Training.
Computer training is essential. For example, the successful use of a “bedside information
system” requires the preparation, involvement and commitment of an entire nursing staff.
Training the nursing staff in IT can be a major educational process.
As physicians are often not employees of a healthcare organization and because they
have little time to learn new tasks, special appeals must be made for them to participate in
the training and use of IT. These appeals should be benefit based, for example, how IT can
save time, improve patient care and enhance status. From a TQM perspective, the training
should be conducted for carefully selected teams of computer users.
5.1.5. Advance Health Care Using Computers
Using computers in health care can improve the quality and effectiveness of care and
reduce its cost. However, adoption of computerized clinical information systems in health
care lags behind use of computers in most other sectors of the economy.
Computers can improve quality and cut costs in many uses.
5.1.5(i). Improved Quality
Automated hospital information systems can help improve quality of care because of
their far-reaching capabilitiesIn addition to alerting physicians to abnormal and changing
clinical values, computers can generate reminders for physicians. For complex problems,
computer workstations can integrate patient records, research plans, and knowledge
databases.
Computers and databases can be used to compare expected results with actual results
and to help physicians make decisions.

The lives of patients can be improved if they use computer systems to obtain information,
make difficult decisions, and contact experts and support groups. NOTES
5.1.5(ii). Decreased Costs
When a physician orders a test by computer, it can automatically display information

that promotes cost-effective testing and treatment.
• Total costs at Wishard Memorial Hospital in Indianapolis decreased $594 per
5.1.5(iii). Vision for the Future
The information superhighway is expected to improve the quality of life for all Americans.
This vision—the National Information Infrastructure—consists of both existing systems
and technologies and others still to emerge, all linked nationwide. Every part of the economy,
including health care, will be affected.
AHCPR strongly supports research to make this vision a reality. A fully functioning
nationwide system will allow the easy yet protected exchange of information among doctors,
nurses, consumers, hospital departments, insurers, and researchers. Americans will benefit
both directly (from immediate access to patient records during emergencies) and indirectly
(from research linking data from many sources).
As part of the High Performance Computing and Communications Program, AHCPR

works with other Federal agencies to provide key computing, communications, and software
technologies to meet the demands of the 21st century. AHCPR-supported researchers
are:
• Developing an entirely paperless medical record system at Beth Israel Hospital in
Boston that links computerized patient records with different departments,
physician offices, and 20 satellite clinics.
• Developing a practical common medical terminology that will be the basis for
computerized patient records, clinical decision support, health services research,
data-driven guideline development, and electronic interchange of patient
information.
5.1.5(iv). Uniform Standards and Data
For information from different databases to be compared, common terminologies

and standards and uniform identifiers are needed.
In supporting the private development of standards, decision analyses, and access

applications, AHCPR works actively with national and international organizations that set
standards. Since 1992, AHCPR has sponsored meetings of the Healthcare Informatics
Standards Planning Panel of the American National Standards Institute (ANSI) and its

DBA 1757
successor, ANSI’s Healthcare Informatics Standards Board. The Board is a private-sector,

NOTES nonprofit coordinator of organizations developing national and international standards.
5.1.5(v).Confidentiality, Privacy, and Security
Improving the quality of care through the use of computerized medical information
systems must not override the need to protect individual rights to privacy. Strong safeguards
must protect confidentiality. Patient rights, provider rights, and other concerns are being
addressed to prevent inadvertent disclosure or alteration of computerized medical records.
5.1.6. The Future Of Integrated Healthcare It
Over the past two decades, the development and adoption of information technologies
(IT) have advanced at breathtaking speed. The first personal computer was built 30 years
ago. Many people remember when the PC first arrived in their office, and now PCs are
standard equipment in almost every office in the world. However, exponential advances in
the ways information is exchanged, and people and equipment are connected, have created
both opportunities and conundrums.
Nowhere are these connections and information exchanges more delicate than in the
healthcare industry. Healthcare organizations must temper the use of personal health data
to advance healthcare efficiencies with the obligation to secure exchanges of such data in
order to protect patient privacy and safety. They need electronic environments in which
data are easily available to appropriate participants in the healthcare delivery process, but
at the same time they have to ensure that conduits for health information exchange comply
with the patient privacy requirements of the Health Insurance Portability and Accountability
Act of 1996 (HIPAA).
Many healthcare-related IT systems are now in operation. These include the systems
hospitals use for administration and patient care; the systems physicians use for patient
scheduling, reimbursement, and maintaining electronic medical records; and the systems
medical device and pharmaceutical manufacturers use in running their businesses, particularly
in the areas of process and quality control. Although these healthcare stakeholders may
regularly install new software and IT hardware, many healthcare providers and
manufacturers continue to depend on paper-based systems to manage the aforementioned
tasks. And despite the high level of IT connectivity that has been developed, many of the
electronic systems in place operate in a silo or do little more than duplicate electronically
the information contained in paper-based systems.
At some point, regulatory, market, and other pressures will force all of these healthcare
IT systems to integrate.

5.1.7. Smart Cards

NOTES
The healthcare market is poised to move from a paper world to an electronic one. In
an era of managed care, specialized medicine, thin financial margins, identity fraud, difficult
insurance claims, and government demand for secure, portable, and confidential patient
information, the competitiveness of healthcare providers may depend on effective use of
information technology (IT). However, increased computerization, reliance on databases,
and movement of sensitive patient information require strict controls to safeguard the security
and confidentiality of healthcare records.
As the industry advances electronically, data protection is a key concern, fueled in

part by legislation such as the Health Insurance Portability and Accountability Act (HIPAA).
Current healthcare requires immediate and secure information access without compromised
privacy. Smart card technology represents a unique opportunity to provide healthcare
solutions that combine secure information access and management with data mobility and
patient privacy.
Healthcare administrators are currently major consumers of paper and ink. Keeping
patient records, submitting medical claims, making referrals, writing prescriptions, and
booking appointments are typically manual processes. The few areas that are automated
tend to operate independently of each other. Only a minority of physician practices store
patient data electronically. Physicians and other healthcare professionals have a stubborn
affinity for using paper-based media to collect and retain patient data.
The use of smart cards can reduce healthcare paperwork and protect patient records.
The smart card can hold encrypted patient information and use a digital signature or a
biometric template to reduce ambiguity about the cardholder’s identity. The use of smart
cards can also reduce the incidence of fraud in health benefit claims–a significant issue for
the Federal government. And while HIPAA does not call for the use of specific technologies,
it is likely that many healthcare enterprises will choose smart card-based solutions because
of their ability to support secure data handling and reduce fraud.
Smart card technology can also improve the healthcare insurance process. Currently,
eligibility verification and claims processing are too often characterized by redundant
information collection, multiple reimbursement forms and lengthy delays. Paper-based
manual processes greatly increase the risk of human error which results in significant
avoidable costs to insurers, national health agencies, and healthcare providers. Too often,
these processes result in significant delays in referral, treatment, and reimbursement for
insured patients.
Smart cards can provide clean data for eligibility verification and claims processing.
They not only can prevent administrative errors and streamline the payment process, they
can also prevent medical errors that arise when one practitioner doesn’t know what another

DBA 1757
has been doing. Test results conducted by one practitioner can be available to all practitioners.
NOTES Before prescribing a drug, a physician can review a patient’s recent diagnoses, allergies,
and prescription history and be aware of any over-the-counter drugs that could conflict
with the proposed course of treatment. In the long run, the data carried by smart health
cards not only can prevent illness and save lives, they also can save the healthcare industry
billions of dollars.
Today, many patients lack control over their health records. Smart cards are among
the few electronic devices that enhance both control and privacy. No one can read what is
contained on the smart card’s microchip or use the card to access computerized records
without a personal identification number (PIN) and authorized hardware and software.
Further, smart cards interact reliably with a wide range of systems. They can operate over
the Internet to verify information in a carrier’s database, and they can be read and updated
offline at a physician’s office, when medical clerks prepare electronic claims for submission
to an insurer.
Moreover, the ability of smart cards to disaggregate data and encrypt information can
protect an individual’s right to privacy while still allowing multiple healthcare facilities to
share patient information more efficiently. Smart cards can carry important health information
and participate in the health information system’s billing and collection functions. Smart
cards can also play a key role in areas such as clinical research where provisions for
confidentiality and patient control of data access encourage patients to participate in research
studies.
Regardless of whether the smart health card stores critical medical data and clinical
information or acts as a secure key to open distributed repositories of patient information,
it is a concept whose time has come. Smart cards are a practical enabling technology that
can enhance the privacy and confidentiality of patient information. They are intuitively easy
to use and work in a very similar manner to credit cards, which have become so ingrained
in our society
5.1.8. Delivery Network Model
There is no perfect healthcare delivery system for a country. Some models seem to
work better than others but each has its own advantages and drawbacks. Broadly, healthcare
delivery models could be classified under tiered system or diffuse system.The tiered system
is made up of regionalized systems of healthcare delivery divided into Primary care,

Secondary care and Tertiary care. Such a pyramidal system is more common in UK and in
HMOs (Health Maintenance Organizations) in US.

5.1.8(i). Types of Delivery Network Models

NOTES
In the late 19th and early 20th centuries, contract doctors existed in many parts of
United States. Large organizations and philanthropic societies employed physicians under
salaries or capitated (fixed pre-payment) contracts. In a capitated system, providers are
paid a fixed amount per patient per month regardless of the quantum of services utilized.
This slowly lost popularity due to increasing competition for contracts and price wars.
In the later half of 20th century, fee-for-service was the dominant model of healthcare
delivery. The physicians were affiliated with a hospital as staff members and had admitting
privileges. They wielded considerable power since they could chose to admit to the hospital
of their choice. They were not employed by the hospital and the specialists were dependant
on a referral network of physicians affiliated with the same hospital or a different group.
In a group practice, a number of physicians, usually from multiple specialties, come

together to setup a group practice. Some of the senior physicians have ownership stake in
the practice. Most of other physicians are compensated through a mix of salary and bonuses.
The practice bills the insurance plans or the patients on a fee-for-service basis. The group
practices try to coordinate care amongst physicians in the practice.
Community health centers were the earliest alternative to fee-for-service setups. They
managed health of entire community rather focusing just on walk in patients. These took
the form of neighborhood health centers, homeless clinics or clinics for immigrants providing
a mix of clinical and public health services.
HMOs originated when large cooperatives or public sector employers started taking
onus of delivering care for their members for a nominal fee. They evolved Health Insurance
Plans where the employers paid a fixed amount per employee to the healthcare provider
bringing together financing and delivery of care into one entity. This prepaid model of care
was renamed HMOs which subsequently evolved into network HMOs.
An HMO which provides full services from primary to tertiary care is known as a
Vertically Integrated HMO. It owns a health plan and either owns or has contracts with
group practices or hospitals.
Some physicians may form groups or associations just for the purpose of negotiating
and administering contracts. Independent Practice Associations (IPA) were formed when
insurance companies, hospitals or local governments started contracting with individual
fee-for-service physicians, office based physician group practices. The IPA is responsible
for the network of physicians which is not linked to the HMOs plan. In some arrangements,
physicians can contract with different HMOs or IPAs. A variance to this structure is Integrated
Medical Group (IMG) in which physicians are employees rather than owners of their

DBA 1757
practices. IPAs and IMGs could also provide care under capitated system, assuming the
NOTES financial risk of providing care.
IPAs, IMGs and HMOs operate in a largely similar structure; however, the “Virtual
Integrated” groups enter into contracts for provision of all services putting them in contrast
with the Vertically intergrated HMOs.
A POS (Point of Service) plan gives the HMO plan members to get healthcare services
from physicians who are not on the HMO’s provider panel. Usually they are required to
pay higher co-pay for such services unlike in HMO where they would have paid the whole
amount.
PPO (Preferred Provider Organization) plans differ from HMOs in the way they
compensate their panel providers. The contracts are based on fee for service payments
unlike HMOs limiting the financial risk to physicians and hospitals. The PPOs are able to
negotiate reduced rates with providers in return of the increased availability of patient
pool.
With the introduction of HMO model, the HMOs controlled the patient base through
contracts removing physician’s admitting discretion to their choice of hospital. This has
given hospital administrator better position in the power equation. According to recent
data, PPOs are becoming popular over HMO plans.
The other important systems are Medicare, Medicaid and governmental health
programs. The Employers and Medicare beneficiaries pay into the federal Medicare program
fund during their employment for subsequent coverage. The healthcare service provider
they visit bills the insurer which gets its payment from Medicare. Under the Medicaid
program, the Medicaid enrollee gets coverage from the program and the provider bills the
payor, which gets payment from Medicaid program.
The four models are given below
Primary care
Refers to the activities concerned with prevention and treatment of common medical
problems in outpatient setting. Care is delivered by primary care practitioners (PCPs) in
the US or general practitioners (GPs) in the UK. A PCP could be responsible for 2000-
3000 patients and is responsible for managing patient’s overall care.
Secondary care
Concerns with treatment of disorders requiring specialist opinion or hospitalization.

The patients are usually referred from Primary care and the physicians are affiliated to a
hospital or a group practice.

Tertiary care
NOTES
Provides medical and/or surgical management of complex disorders in an inpatient
setting and usually requiring collaboration between multiple specialties. These are super-
specialized standalone hospitals or specialty departments in a multi-specialty hospital.
Diffuse system
In the diffuse system there is no such division. In this system patients can directly
approach specialists without consulting GPs or PCPs first. The boundaries between GPs,
internists, family practitioners and pediatricians are blurred. Many internal medicine specialists
provide primary care, many family practitioners provide secondary care. However, some
centers have designated “hospitalists” for inpatient care. The diffuse system is the relatively
more common in United States. It is a diamond type of system with most hospitals providing
a mix of multi-specialty secondary and tertiary services. The stress is on getting the latest
technology and advanced clinical care closer to home.
5.1.8(ii)..Integrated Systems And Employer Driven Payment Systems
The integrated system and the employer Driven Payment system are discussed below.
Integrated system
Group practices: They may or may not contract with HMOs. Management Services
Organizations (MSOs) are specialized agencies for the management of physician practices.
Sometimes they also act as the source of capital. MSO services could include billing, claim
processing, administration, contract management, utilization management, quality control.
MSOs could also own the assets related to practice such as office space, equipment,
support staff. Sometimes MSOs buy out physician practices using outside funding and
becomes a Physician Practice Management company.
Physician Hospital organization: A PHO is formed to exert greater negotiation power

against MCOs. They are a type of arrangement between physicians and hospitals and are
usually affiliated with one hospital. They can directly contract with employers too.
Integrated Delivery Systems (IDS): IDS are the strategic arrangements between
hospitals, physicians and insurers to provide full spectrum of healthcare services to a given
population. Managed care organizations contract with IDS instead of each of different
players. Larger size of IDS can facilitate investment in capital expenditure.
Employer driven payment systems
Employer provides health insurance to individuals who seek care from provider which
bills a payor or insurer. In the case of large employer which is self insured, the bills would
come back to the employer and payor combination. In such cases the insurance companies

DBA 1757
usually act as ASOs (Administrative Service Organization) for the employers providing
NOTES administrative support.
For individuals who are ineligible for group insurance, individual policies are available.
In this system, the individuals who are self employed or on individual policies seek coverage
from an insurer which reimburses the providers providing service to the individuals.
5.1.8(iii). Future Trends
In United States, the healthcare administration is largely outside the governmental

control. This leaves hospital capacity regulation, residency seat allocation and coordination
of care amongst primary, secondary and tertiary centers in the hands of private entities.
The physician groups control the policy, occupational standards and entry requirements
for licensing. So their professional interests and favor for technology and inpatient capacity
also led to expansion of hospital facilities. Over the last few decades, the healthcare has
increasingly been delivered at hospitals rather than physician offices. With emerging
consumer driven healthcare models and advanced surgical techniques, there is a gradual
shift towards Ambulatory Clinics. This will introduce newer models of healthcare delivery.
QUESTIONS
5.1 a what are the Challenges in healthcare delivery system today?
5.1.b.Explain the Managerial Implications of healthcare delivery system.
5.1.c Explain the future of Integrated Healthcare IT.
5.1.d.What is a Smart card?
5.1.e.Explain the types of of delivery models.
Summmary
In this chapter, you have learned the challenges I health care system, managerial
implications of healthcare systems and the future trends in Integrated healthcare IT. Also
you understood what is a Smart card and also the types of delivery models.
EXERCISE
1. Visit a nearby hospital and discuss with the employees of the hospital regarding
how health care services are delivered in their hospital.
2. Explain the functioning of smart card in health care industry. Browse the net and
obtain the answer.

CHAPTER 2
NOTES
5.2 MAINTAINING COMPUTERIZED HEALTH DATABASES
5.2.1. Introduction
Computerized medical information systems are at the start of what promises to be a

rapid evolution. We are still in a position to look ahead and consider the promise and
pitfalls of such systems as we design and deploy them. We need not feel wedded to the
structure and processes of current systems. In fact, it seems increasingly unlikely that an
electronic longitudinal medical record will be produced as an outgrowth of the traditional
institutional medical record.
In order for electronic medical records to eliminate the fragmentation of health

information, be universally accessible, and guard patients’ privacy, systems must be built
according to public standards and controlled by patients.
After reading this chapter, you will understand

the maintenance of computerized Health databases
the guidelines for developing Electronic medical record in databases
the characteristics of Electronic medical record
what are the challenges and limitations of electronic medical records
the Practice guidelines for Health information and record systems
5.2.3. Maintaining Computerized Health Data Bases
A patient’s medical records are generally fragmented across multiple treatment sites,
posing an obstacle to clinical care, research, and public health efforts. Electronic medical
records and the internet provide a technical infrastructure on which to build longitudinal
medical records that can be integrated across sites of care. Choices about the structure
and ownership of these records will have profound impact on the accessibility and privacy
of patient information. Already, alarming trends are apparent as proprietary online medical
record systems are developed and deployed. The technology promising to unify the currently
disparate pieces of a patient’s medical record may actually threaten the accessibility of the
information and compromise patients’ privacy. Let us study the two doctrines and six
desirable characteristics to guide the development of online medical record systems. Let us
study how such systems could be developed and used clinically.

DBA 1757
5.2.3(i) Access And Privacy

NOTES
No single institution can hope to encompass a patient’s entire record. Ideally, it
should be possible to create or assemble each patient’s personal health record so that it is
accessible at all points of care within the health service and contains data from all institutions
involved in that patient’s care. Two main impediments stand in the way of this ideal. Firstly,
most healthcare institutions do not provide effective access for patients to their own data
and, despite technical feasibility,they show little willingness to share data with their
competitors. Secondly, patients are becoming increasingly anxious about the privacy of
their medical records. Such concerns seem justified when one considers that, under current
laws and practices, identifiable medical data are routinely shared with insurance companies,
government, researchers, employers, state bureaus of vital statistics, pharmacy benefit
managers (companies that track doctors’ drug prescriptions), local retail pharmacies,
attorneys, and others.
5.2.4. Guldelines for Developing Electronic Medical Records in Data Bases
Let us study the guidelines for the development of electronic medical records:
firstly, that record systems should be designed so that they can exchange all their stored
data according to public standards and, secondly, that patients should have control over
access and permissions. Building software compliant with public standards will enable
connectivity and interoperability even of diverse systems. Patients’ control will allow
protection of privacy according to individual preferences and help prevent some of the
current misuses of personal medical information. The purpose behind these guidelines is to
ensure long term access of patients and care providers to medical records for clinical use
while minimizing the risk to patients’ privacy.
5.2.4(i).Public standards
Some of the stresses on the doctor-patient relationship could be eased by using

computerised and internet based tools for decision support, communications, and
documentation.As medical care increasingly depends on computerization, software
engineering and marketing practices become more relevant to issues of healthcare delivery
and patients’ rights. Unfortunately, many current systems fragment medical records by using
incompatible means of acquiring, processing, storing, and communicating data. These
incompatibilities may result from a failure to recognize the need for interoperability or they
may be deliberate, with the aim of locking consumers into using a particular system. Either
way, the practice precludes sharing of data across different applications and institutions.
The alternative to proprietary methods is the use of open standards. At minimum,

open standards should be used in the exchange of information among different systems.
For example, HL7 (Health Level Seven) is a voluntary consensus standard for electronic
data exchange in healthcare environments. It defines standard message formats for sending

or receiving data on patient admissions, registration, discharge, or transfer; queries; orders;

results; clinical observations; and billing. Using an open messaging standard such as HL7 NOTES
allows different health applications, such as a laboratory system and a record system, to
“talk” to each other.
Other standards have been adopted for various other data exchanges: DICOM defines
messages for encoding and exchanging medical images, and X12 is a recent set of standards
for exchanging authorisation, referral, and billing records. Standards such as CorbaMED
try to define universal object models that can be widely used among different interoperating
systems. Programs that exchange data according to open standards may nevertheless store
and use those data internally in proprietary ways.
For different systems to share data effectively, they must all use at least a common set
of communication protocols and message formats and allow the import and export of all
their data. Common data structures and open source programming can foster the possibility
of effective data exchange among systems.
5.2.4(ii)Patient control
Substantial problems arise if patients cannot trust that their medical data will be used
only in the ways they intend. If patients feel that they have no control over the fate of their
medical information, they might fail to disclose important medical data or even avoid seeking
medical care because of concern over denial of insurance, loss of employment or housing
and embarrassment. Expectation of privacy allows trust and improves communications
between doctors and patients.
Patients are poised to take control of their personal medical information. People are
already managing bank accounts, investments, and purchases on line, and many use the
web for gathering information about medical conditions. Consumers will naturally expect to
extend this control to online medical portfolios.
The fact that patients have trouble accessing their medical information while that very
information is being used for unregulated secondary uses has exacerbated worries about
the confidentiality and proper use of that record. A particular concern about online medical
data is that companies providing the record software or maintaining the record systems
want to own the patients’ data. Giving patients control over permission to view their record
as well as over its creation, collation, annotation, modification, dissemination, use, and
deletionis key to ensuring patients’ access to their own medical information while protecting
their privacy.
5.2.5. Characteristics of electronic medical record
In order to comply with the doctrines of public standards and patient control, designers
of medical record systems should strive to include the following characteristics.

DBA 1757
5.2.5(i)Comprehensiveness
NOTES
Because care is normally provided to a patient by different doctors, nurses,
pharmacists, and ancillary providers, and, with the passage of time, by different institutions
in different geographical areas, each provider must be able to know what others are currently
doing and what has previously been done. Outpatient records should contain, at least,
problem lists, procedures, allergies, medications, immunisations, history of visits, family
medical history, test results, doctors and nursing notes, referral and discharge summaries,
patient-provider communications and patient directives. The records must also span a lifetime,
so that a patient’s medical and treatment history is available as a baseline and for retrospective
analysis.
5.2.5(ii) Accessibility
Medical records may be needed on a predictable basis (as at a scheduled doctor’s

visit) or on the spur of the moment (as in an emergency). They may be needed at a patient’s
usual place of care or far from home. They may be needed when the patient can consent to
their use or when he or she is unconscious and only personal or societal policy can dictate
use. Ideally, the records would be with the patient at all times, but alternatively they should
be universally available, such as on the World Wide Web. In addition, with patients
permission, these records should be accessible to and usable by researchers and public
health authorities.
5.2.5(iii) Interoperability
Different computerized medical systems should be able to share records: they should
be able to accept data (historical, radiological, laboratory, etc) from multiple sources,
including doctors’ offices, hospital computer systems, laboratories, and patients’ personal
computers. Without interoperability, even electronic medical records will remain fragmented.
5.2.5(iv) Confidentiality
Patients should have the right to decide who can examine and alter what part of their
medical records. In principle a patient might choose to allow no access to such records,
though at the risk of receiving uninformed and thus inferior care. At the other extreme some
might have no hesitation in making their records completely public. For most patients, the
appropriate degree of confidentiality will fall in between and will be a compromise between
privacy and the desire to receive informed help from medical practitioners. Because an
individual may have different preferences about different aspects of his or her medical
history, access to various parts of the record should be authorised independently. For
example, psychiatric notes may deserve closer protection than immunisation history. Further,
patients should be able to grant different access rights to different providers, based either
on their role or on the particular individual. Most patients will probably also choose to
provide a confidentiality “override” policy that would allow an authenticated healthcare

provider in an emergency to gain access to records that he or she would not normally be
able to, though at the cost of triggering an automatic audit. NOTES
5.2.5(v)Accountability
Any access to or modification of a patient’s record should be recorded and visible to

the patient. Thus, data and judgments entered into the record must be identifiable by their
source. Patients should be able to annotate and challenge interpretations in their records,
though we believe they should not be able to delete or alter information entered by others.
Patients should also be able to see who has accessed any parts of their record, under what
circumstances, and for what purpose. Reliable authentication is essential to make this feasible.
Appropriate laws can reinforce accountability built into the records system.
5.2.5(vi)Flexibility
Most people want to make data about themselves available to those genuinely trying
to improve medical knowledge, the practice of medicine, the cost effectiveness of care,
and the education of the next generation of healthcare providers. This altruism has limits,
however, when patients feel the threat of exploitation, the risk to privacy, or the annoyance
of unsolicited follow up contacts. Patients should therefore be able to grant or deny study
access to selected personal medical data. This can be based on personal policies or decisions
about specific studies.
Patients may also agree to more intrusive participation in specific studies. Whether
patients are willing to be solicited on the basis of characteristics of their record should also
be controllable. Patients could provide time limited keys to other parties to access a specified
segment of their record. For example, they could permit hospitals to write to (but not read)
the laboratory results section of their record. Or they could provide public health authorities
with access to their immunization history. All these patient functions should be accessible
from any web browser in the world.
5.2.6.Challenness and Limitationss Of Electrons Ofelectronic Medical Record

In Databases
No matter how sophisticated security systems become, people will always manage
to defeat them. If by no other means, they may be able to exploit human weakness to
subvert someone with legitimate access to the data. Fortunately, technical advances in security
systems for electronic records should continue to be driven forward by the commercial
interests of companies doing business over the internet. In fact, we may need considerable
further evolution of accepted policies and laws so that patients are not coerced into signing
away their privacy rights to obtain care or reimbursement.
The widespread adoption of patient controlled health records will depend on solutions
being found to several challenging technical and policy issues. No computer system has

DBA 1757
ever remained operational for the lifetime of a typical person; hence we will need procedures
NOTES to migrate records to new computer systems and architectures. The contentious issue of
how patients may be uniquely identified might entangle our design choices and desire for a
distributed system of records. We will need to develop acceptable procedures for backing
up data, anticipating recovery in case of disasters, agreeing on whether emergency overrides
of patient’s policies are ever acceptable, whether it is possible to retract access to data
once it has been given, who is trusted to conduct audits and what rights they have to
sanction violators of policy, and many other procedures.
5.2.7. Practice guidelines for health information and record systems
5.2.7.(i).Record systems, organization and maintenance
A medical record must be maintained for every resident in a long term care facility.
With varying levels of automation, there may be some records maintained electronically
and some in paper format. This section of the report will deal with maintenance of the
paper medical record.
It is critical that every facility have formalized systems in place for the maintenance of
their records. Records should be systematically organized and readily accessible. The
following practice guidelines establish a baseline for the systems that should be in place for
maintaining the record systems in a facility.
5.2.7.(ii).Maintaining a Unit Record
A unit record and unit numbering system is recommended for long term care facilities.
With a unit record, the patient is assigned a medical record number on the first admission
which is retained for all subsequent admissions/readmissions. The patient’s entire medical
record is thus filed together as a unit under one number (there may be multiple volumes and
folders).
In long term care, the record from previous admissions should be brought forward to
be filed with the current admission. All records from previous admissions are pulled forward
and usually maintained in the overflow files. It is best to separate the past records for a
current admission from the discharge record files so the chart is not inadvertently filed in
storage and destroyed.
Bringing previous charts forward will provide the most comprehensive picture of the
residents medical history and therapy. The previous records should be readily accessible
to staff for use in the assessment and care planning process.
The medical records from previous stays remain in their original file folder and are
retained chronologically with other records for patients currently admitted to the facility.
The records from one discharge to another are not combined into one folder.

5.2.7.(iii).Assigning a Medical Record Number

NOTES
Each resident admitted to the long term care facility should be assigned a unique
medical record number. The following are general rules to follow when assigning medical
record numbers:
• Assign a medical record number only after a resident is admitted. This will prevent
numbers from being assigned when the resident is not actually admitted to the
facility.
• Assign numbers chronologically. Each new admission is assigned the next sequential
number.
• Exception: For any subsequent admissions, reassign the previous medical record
number. You may use a modifier to the medical record number to designate multiple
admissions. For example: 1234 – a or 1234 – Always verify in the master patient
index that the resident had not been in the facility before.
• If a resident was assigned a number, but was not admitted, make a notation in the
admission/discharge register that the resident was not admitted.
5.2.7.(iv).Maintaining Records in a Continuum of Care
For healthcare campuses or continsuums it is recommended that separate records

are kept for each of the different care settings.
When transferring between care settings, it is recommended that an interdisciplinary

transfer form or discharge instructions be completed to assure continuity of care. Include
copies of relevant documentation to facilitate the assessment and care planning process.
Health information staff should oversee record management, storage, retention, and
destruction for the medical records maintained by the campus to assure that the medical
records for each of the care settings are maintained in an organized and systematic filing
and retrieval system.
To assist with tracking medical record numbers/campus numbers, admissions,

discharges and transfers there should be a campus-wide master patient index maintained
or another mechanism to link all records to the resident.
5.2.7.v).Defining What is Part of the Medical Record
The medical record in a long term care facility reflects the multi-disciplinary approach
to assessment, care planning and care delivery. The medical record includes but is not
limited to the following type of information: Resident identification, admission/readmission
documentation, advance directives and consents, history and physical exams and other
related hospital records, assessments, MDS, care plan, physicians orders, physician and
professional consult progress notes, nursing documentation/progress notes, medication
and treatment records, reports from lab, x-rays and other diagnostic tests, rehabilitation
and restorative therapy records, social service documentation, activity documentation,

DBA 1757
nutrition services documentation, and other miscellaneous records including correspondence

NOTES and administrative documents.
Facility policy should specifically outline in the format of a chart order the exact
documents and records that will be considered part of the medical record. If portions of
the record will be retained in an electronic medical record system, policies should differentiate
between those records that will be paper-based and those that are electronic.
5.2.7.(vi).Maintenance of the Medical Record
It is critical that both the active record and the overflow records are maintained in a
systematically organized fashion. This means that all records have an established chart
order or order of filing that is followed. All records (records on the nursing station, overflow
records, and discharge records) should be readily accessible, maintained in an organized
chart order, filed in an easily retrievable manner, and maintained in folders or chart holders
sufficient in size for the volume of the record. The chart holders and folders should be kept
neat, clean and orderly.
It is recommended that a chart order or order of filing with thinning guidelines be kept
in the record and at the nursing station to direct staff to the proper location of forms.
5.2.7.(vii).Identification (Name and Number) on pages of the Medical Record
From a legal perspective, each page or individual documents in the medical record
should contain resident identification information. At a minimum, both the resident name
and medical record number should be on each form. If labels/label paper is used, resident
identification information must be included on the label. The name and number should be
placed on both sides of a page because records are frequently copied and both sides may
not be included. The name of the form should also be printed on both sides of a two-sided
form.
For example, identification information can be written on the page in permanent ink,
stamped using an addressograph, or affixed with a label placed. Resident specific information
printed from a computer system to be filed in the medical record should include resident
identification information on each page.
5.2.7.(viii).Common Forms and Guidelines
This section outlines the common chart forms found in a long term care record. The
titles, location in the record may be different, but the guideline would remain consistent for
the type of documentation contained. Thinning the medical record is a process of removing
records older than a certain date and moving them into a secondary record known as the
overflow record.

NOTES

DBA 1757
NOTES

NOTES

DBA 1757
NOTES
Note: Thechart forms and location are not meant to represent a recommended chart
order or forms. Chart order and the types of forms used are facility-specific. The forms
named represent common types of documentation found in a long term care record.
QUESTIONS
5.2. a. Describe computerized Health databases.
5.2. b.Explain Access and Privacy in maintaining computerized health Databases.
5.3. c.Explain the guidelines for developing Electronic medical records in databases.
5.3. d.Define and explain the characteristics of Electronic medical record.
5.3. e.What are the challenges and limitations of medical record in Electronic Databases.
5.3. f.Explain the practice guidelines for health information and record systems..
SUMMARY.
In this chapter, you have learned about the maintenance of computerized health
databases, its guidelines, characteristics, challenges& limitations and practice guidelines
for health information and record systems.
EXERCISES
1. Obtain from the net the type of databases used in corporate hospitals.
2. Also learn the database design of large databases in corporate hospitals.

NOTES
CHAPTER 3
5.3 EVALUATION OF COMPUTERIZED MEDICAL RECORDS
5.3.1. Introduction
In the new millennium, information technology will catalyze dramatic change in many
aspects of medicine, including patient records. Good medical care requires accurate records
of greater detail than in the past. Malpractice protection mandates more organized and
complete records. Third party payers are requiring more justification for the expenses
generated by physicians actions. Today’s economics require more efficient and cost-effective
methods of keeping the patient’s clinical records. “Computer based Records and Computer
based systems can respond to health care’s need for a ‘central nervous system’ to manage
the complexities of modern medicine — from patient care to public health to health care
policy.” The Computer based Records eliminates paper records and allows immediate
access to notes and test results, including imaging reports and actual radiographs locally
and between facilities. The computer patient records system also includes a decision support
system that informs physicians about potential drug interactions and appropriate laboratory
tests as well as telemedicine support for other centers and consolidation of resources.
Electronic medical records have long been available and are becoming more prevalent
in health care in the United States. Recently, the Institute of Medicine strongly urged electronic
medical record (EMR) use to improve the quality of care and patient safety. The definition
of an EMR varies, but a complete EMR includes clinical documentation (notes), patient
data (e.g., labs, radiology results, other test results), and computerized order entry (for
tests and medications). Other added features include messaging between providers and
staff, decision support systems, and patient access to information.
Standards organizations such as the American Society for Testing and Materials
(ASTM) and Health Level 7 (HL7) have published guidelines that address the correction
and amendment of computerized patient record entries.
5.3.2.Learning Objectives
After reading this chapter, you would be able to understand
• Guidelines for computerized patient record entries

• What is a Electronic Medical Record
• The risks in computerized medical information system

DBA 1757
• Models used for evaluation of medical records
NOTES
• How to evaluate the complex health information system
5.3.3. Guidelines for Computerized Patient Record Entries
5.3.3(i) Astm Guidelines
In section 8, three types of authentication methods are introduced and defined.
8.2.2.15 Addendum Signature: “The signature on a new amended document of an

individual who has corrected, edited, or amended an original health information document.
An addendum signature can either be a signature type or a signature sub-type.” (Signature
types and signature sub-types are defined in section 8.1 of the signature attributes section
of the E1762).
The ASTM standard states that “any document with an addendum signature shall
have a companion document that is the original document with its original, unaltered content,
and original signatures. A computer code attribute shall be used to reference the original
document to the new document. Whether the original unaltered document is displayed
each time the addendum is viewed is left to the individual facility’s discretion. However, the
original, unaltered document must remain as part of the computerized patient record and
the system must permit access to the original document on demand.”
8.2.2.16 Modification Signature: “The signature on an original document of an individual

who has generated a new amended document.”
The standard states that “the original document shall reference the new document via
an additional signature purpose. This is the inverse of an addendum signature and provides
a pointer from the original to the amended document.”
8.2.2.17 Administrative (Error/Edit) Signature: “The signature of an individual who is

certifying that the document is invalidated by an error(s), or is placed in the wrong chart.”
The standard states that “an administrative (error/edit) signature must include an
addendum to the document and therefore shall have an addendum signature sub-type.
This signature is reserved for the highest health information system administrative
classification, since it is a statement that the entire document should no longer be used for
patient care, although for legal reasons the document must remain part of the permanent
patient record.”

5.3.3(ii).HL7 Guidelines
NOTES
This section identifies and defines the types of errors and corrections that occur in the
appropriate computer messages, which in turn should be used to communicate corrections
and addenda. The elements utilized for document addendum notification are outlined and
defined in sections 9.4.5 through 9.4.11.
HL7 offers scenarios for each of the following situations:
• creating an addendum—”Author dictates additional information as an addendum

to a previously transcribed document. A new document is transcribed. This
addendum has its own new unique document ID that is linked to the original
document via the parent ID. Addendum document notification is transmitted. This
creates a composite document.”
• correcting errors discovered in a document that has not been made available for
patient care—”Errors, which need to be corrected, are discovered in a document.
The original document is edited, and an edit notification is sent.”
• correcting errors discovered in the original document that has been made available
for patient care—”Errors discovered in a document are corrected. The original
document is replaced with the revised document. The replacement document has
its own new unique document ID that is linked to the original document via the
parent ID. The availability status of the original document is changed to ‘obsolete’
but the original document should be retained in the system for historical reference.
Document replacement notification is sent.”
• notification of a cancelled document—”When the author dictated a document, the

wrong patient identification was given, and the document was transcribed and sent
to the wrong patient’s record. When the error is discovered, a cancellation notice
is sent to remove the document from general access in the wrong patient’s record.
In these cases, a reason should be supplied in the cancellation message. To protect
patient privacy, the correct patient’s identifying information should not be placed
on the erroneous document that is retained in the wrong patient’s record for historical
reference. A new document notification and content will be created using a TO2
(original documentation notification and content event) and sent for association
with the correct patient’s record.”

DBA 1757
5.3.4. Electronic Medical Record

NOTES
Electronic Medical Record: A term that may be treated synonymously with computer-
based patient record and/or electronic health record; often used in the US to refer to an
electronic health record in a physician office setting or a computerized system of files
(often scanned via a document imaging system) rather than individual data elements.
This technology, when fully developed, meets provider needs for real-time data access
and evaluation in medical care. Together with clinical workstations and clinical data
repository technologies, the EMR provides the mechanism for longitudinal data storage
and access. A motivation for healthcare entities to implement this technology derives from
the need for medical outcome studies, more efficient care, speedier communication among
providers and management of health plans.
What is the difference between an EHR and an EMR?
Not much, if any. The world of medical practice software is constantly seeking new
ways to describe the various options out there for doctors. However, not many can keep
all of it straight, so everyone just uses what they feel to be the most popular acronym. At
EMRWorld, we tend to use EMR, electronic medical records, or sometimes EHR,
electronic health records.
EMR use and potential benefits. An EMR can provide the electronic infrastructure
for eight types of clinical and administrative activities normally conducted in physician
practices. Commercial EMR systems vary in their capabilities for each type of activity,
while practices and physicians vary greatly in how extensively they use available EMR
capabilities.
Viewing. All practices used EMR viewing capabilities, which improve chart availability,
data organization, and legibility. Quality benefits depended on the amount of viewable
clinical data.
Documentation and care management. There is a consistent relationship between

greater electronic documentation by physicians and greater quality improvement and financial
benefits.
In most practices the bulk of EMR-related financial benefits come from reductions in
medical records and transcription staff as physicians moved from dictation to typing their
own notes. Some practices increase their billing revenue through more complete capture
of services and decreased undercoding of services provided.

Ordering. Basic use of electronic ordering typically consists of physicians’ typing in

prescription orders, responding to drug interactions and drug allergy alerts, and printing NOTES
out prescriptions
In large practices, basic ordering often includes electronic ordering of referrals and
laboratory and radiology tests. More advanced ordering capabilities includes additional
decision support, electronic transmission of orders to pharmacies and laboratories, and
better tracking of test-order status and test results, all of which can improve quality and
decrease errors.
Messaging. Basic use of electronic messaging among providers improves the availability,
timeliness, and accuracy of messages and increased completeness of documentation, thus
potentially reducing “dropped balls” and safety problems. Analysis and reporting.
Practices also use physician performance monitoring and feedback capabilities to improve
quality and efficiency.
Patient-directed functionality. Most practices have limited or nonexistent practice Web

sites for patients. A few large-practice Web sites enable patients to schedule visits, send
secure e-mail messages to providers, receive e-mail reminders, order medications, access
their charts, and obtain more individualized educational patient care information—all of
which have the potential to improve quality.
Billing. Increased integration between billing and EMR software, combined with electronic
documentation, can yield financial benefits through more complete capture of services
provided, more defensible Medicare coding at higher coding levels, and reductions in
data-entry staff.
Electronic medical records software system: Many systems are available and require
standardization for ease of use among physicians; many clinicians may need further computer
training, so available systems should be designed to decrease administrative work for
physicians and enhance the physician-patient relationship.
The following are the 8 core functions that an electronic medical records software
system should have:
• Health information and patient data
• Laboratory results management
• Computerized order management
• Decision support system
• Electronic communication and connectivity

DBA 1757
NOTES • Patient support and education

• Administrative processes
Additionally, the following functionalities help better adoption of the CPR by physicians:
• Transition or flexibility in moving from desktop to handheld computing devices

• Structured data entry to accommodate the diversity of specialized care
• Options to express findings and conclusions in free text or definition of normal
• Graphical data entry for body maps and radiology images
• Improvement of transcription and upload process
• Enhancement of faxback service and upgrade to electronic file transfer or Web
access service
• Enhancement of decision support systems and implementation of artificial
intelligence such as drug interaction service and various clinical guidelines
A system called Vista-Office EHR is a new high-quality electronic health record (EHR)
system for use in small physician offices.
Vista-Office EHR includes the existing Vista functions of order entry, documentation,
and results reporting. It also has been enhanced in the areas of physician-office patient
registration, interface possibilities to existing billing systems, and reporting of quality measures.
Following are the terms and abbreviations used in medical record.

NOTES

DBA 1757
NOTES
5.3.5. Risks in Computerized Medicl Information System
In a computerized medical information system, we should be clear about what the

risks are for the parties involved before we decide on an effective strategy to implement
security. After weighing these risks, we can then assess the seriousness of these risks and
the potential for these risks to be experienced. Only then we can design an appropriate
security mechanism.
Risks that can be recognized immediately include:

• Adverse health affects due to improper records, including possible loss of life. If a
record contains incorrect information, then the patient may receive incorrect
treatment and suffer ill health effects. This is a problem that exists already in paper-
based systems, and it seems unlikely that it will be exacerbated by going to an
electronic system.
• Liability of providers. If incorrect records result in adverse health effects or other
personal injury, then the party responsible for collecting, storing, and displaying
this data may be held liable. When the medium of storage and delivery of medical
information changes to electronic methods, there will be very little case law to
guide liability decisions. This implies that computerized medical information will
require much stronger methods of authentication and auditing than is currently
used in practice.
• Personal embarrassment. Our medical information is often some of the most sensitive
information that exists about us. It can be an indicator of past or present behaviour
that we might not like to be known widely. This is particularly true of celebrities,
for whom there is a great deal of interest in medical details.

• Loss of opportunity. As medical technology accelerates, we have observed that

much more detailed and specific data collection is possible. At the same time, NOTES
much more sophisticated (and some dubious) inferences can be drawn from this
data. For example, a person’s medical information may be used to make decisions
about suitability for insurability, employment or promotion, political office, or even
as a basis for investment decisions.
5.3.6. Models and Frameworks Commonly used for evaluation
5.3.6.(i).The Delone and McLean Information Systems (IS) Success Model
In a landmark article, focusing primarily on Management Information System (MIS)

applications, Delone and McLean (1992) provided a framework for characterizing and
measuring the success of information systems. The framework includes 6 major dimensions
or categories: system quality, information quality, use, user satisfaction, individual impact,
and organizational impact. System quality measures (measures of the information processing
system itself) tend to be engineering-oriented characteristics of the systems under study,
such as response time, ease of use, system reliability, system accessibility, system flexibility
and system integration. Information quality measures (measures of information system output)
are addressed mostly from the perspective of the user and are therefore subjective in
nature, such as information accuracy, timeliness, completeness, reliability, conciseness,
and relevance.
5.3.6.(ii).Social Interactionist Models
Social Interactionalist Models (Kaplan 1997, 1998) consider relationships between

system characteristics, individual characteristics and organizational characteristics and the
effects among them. Consequently, evaluations based on these models consider not only
the impact of an information system on a organization, but also the impact of the organization
on the information system, and tend to be process-focused. The framework is informed by
theoretical models of organizational change, user reactions to health information systems
and Roger’s work on innovation diffusion.
Evaluation questions within an interactions framework address issues of

Communication, Care, Control and Context (the 4 Cs). The evaluation questions are: (1)
what are the anticipated long term impacts on the ways that departments linked by computers
interact with each other; (2) what are the anticipated long term effects on the delivery of
medical care; (3) will system implementation have an impact on control in the organization;
and (4) to what extent to medical information systems have impacts that depend on the
practice setting in which they are implemented?
5.3.6.(iii).Cognitive Evaluation Approaches
Kushniruk, Patel and Cimino (===1997) identify the need for improved methodologies
for the assessment of medical systems and their user interfaces. Conventional methods of

DBA 1757
evaluation, such as questionnaires and interviews with users, rely on the user’s memory of
NOTES their experience with using a computer system (what they think they did when using the
system) which may be quite different from their actual behavior. Therefore, there is a need
to incorporate into system design and evaluation processes sound methodologies for the
assessment of medical systems and their user interfaces.
5.3.6.(iv).Probe
The purpose of this document is to provide practical guidance for those involved in
the evaluation of Electronic Patient and Health Records in the NHS in Britain and Wales.
The PROBE (Project review and objective evaluation for electronic patient and health
records projects) guidance was prepared by the UK Institute of Health Informatics for the
NHS Information Authority (NHS Information Authority, March 2001), as an extension
and update of the earlier PROBE guidance issued in 1996 by the NHS and as a companion
document to the Evaluation of Electronic Patient and Health Records Projects document
released in January 2001..
PROBE suggests that there are 4 essential standards for an evaluation study which
need to be tested throughout the evaluation planning stage: utility; feasibility; propriety and
accuracy. It also stresses the importance of an evaluation framework, which focuses
stakeholders on the expected benefits and barriers of an EPR/HER and methods of
measuring these. Six steps are proposed to plan an evaluation of an electronic patient
record or electronic health record initiative: (1) agree why an evaluation is needed; (2)
agree when to evaluate; (3) agree what to evaluate; (4) agree how to evaluate; (5) analyze
and report; and (6) assess recommendations and decide on actions.
5.3.6.(v).Total Quality Management (TQM)
Drazen and Little (1992) suggest that new approaches are needed to evaluate clinical
and management applications of health information systems in order to measures benefits
that are important to the institutional sponsors of health information system projects. Proposed
enhancements to the traditional cost-benefit approach to evaluation include: (1) driving to
achieve benefits as the primary evaluation goal, including more than direct cost savings, i.e.
improvement in level of service and improvement in the outcomes of care; (2) focusing on
critical issues and using standard tools to achieve efficiencies, i.e. measure what is important,
not what is easy to measure; (3) maintaining independence, given the involvement of the
private sector in many of the evaluation initiatives; (4) fitting with the institutional philosophy.
5.3.6.(vi).The Team Methodology
A systems perspective informs the model developed Grant, Plante and LeBlanc (2002)
to evaluate the overall function and impact of an information system. Key tenets include:
(1) the processing of information by a system can be distinguished at 3 different interacting
levels: strategic, organizational, and operational, and these levels are a useful way of situating

an evaluation; (2) the evaluation should be dynamic and include both formative and summative
analyses; (3) the evaluation approach must be acceptable in terms of the resources and NOTES
time it requires to complete; and (4) the evaluation should be longitudinal..
5.3.6.(vii).Health Technology Assessment
Kazanjian and Green (2002) propose a Health Technology Assessment Framework

as a conceptual tool for decision-making about health technologies, including information
technologies. The major framework dimensions are (1) population at risk, (2) population
impact, (3) economic concerns, (4) social context (including ethical, legal, and political
concerns), and (5) technology assessment information.
5.3.7. Future Efforts to Evaluate Complex Health Information Systems
The common core components of performance evaluation frameworks in health care

include: clinical outcomes/effectiveness, accessibility, customer/stakeholder satisfaction;
coordination; financial/efficiency, quality; innovation and internal business production. Less
frequently included components are appropriateness, safety, health status and integration..
Until electronic health records are considered a key strategic initiative in the management
and delivery of health services, difficulties in evaluating the impact of such initiatives will be
compounded by lack of progress in implementation. Information technology initiatives are
viewed with suspicion by many. Less than positive results from early evaluations (which
focused only on economic benefits) have mounted additional barriers to future system
development. In most jurisdictions, decision makers, including the central funding agencies
of government, require evidence to support the investment of millions of dollars in health
information system infrastructure.
Some of the key messages extracted from the review of the literature concerning the
need for broader, more inclusive, and yet flexible approaches to evaluation of complex
health information systems include:
• A planned evaluation, introduced at the initial project stages, can help overcome
many obstacles.
• It is important to develop a process for engaging stakeholders, particularly

physicians, in establishing principles and premises for large IS projects
• Evaluation frameworks should: (1) focus on a variety of technical, economic and

organizational concerns; (2) use multiple methods; (3) be modifiable; (4) be
longitudinal; and (5) be formative and summative
• Many formal evaluations of major information technology investments in the public

sector have focused on critiques of implementation rather than assessment of health

DBA 1757
care benefits. The time has come to attempt to quantify benefits not just in more
NOTES focus on prevention, less errors and more evidence-based decision making.
• Evaluation is not just for accountability, but also for development and knowledge
building. Future evaluations should be multi-perspective, multi-method, include
qualitative methods and involve diversely constituted research teams
• Limitations of RCTs identified include: (1) low power - not enough observations(2)
inability to blind subjects to their assigned group (3) costs (4) limited external
validity
• When faced with the challenge of evaluating complex systems which have been
implemented in less than standardized fashion, it is reasonable to focus on the form
and function of the systems implemented (ie the concept of a total health record)
instead of trying to distinguish, for evaluation purposes, the difference between
different systems
5.3.8. Evaluation of Complex Health Information Systems
The following table shows sample questions used for evaluation of complex health
information systems
SAMPLE EVALUATION QUESTIONS
Littlejohns identified 10 evaluation points as given below.
1. Are training, change management and support optimal?

2. Is the reliability of the system (including peripherals, network, hardware and
software) optimal?
3. Assessing the project management
4. Does the system improve the communication of patient information between
healthcare facilities?
5. Is data protection adequate?
6. Assessing the quality and actual use of decision-making information to support
clinicians, hospital management, provincial health executives and the public.
7. Are patient administration processes more standardized and efficient?
8. Has revenue collection improved?
9. Is information being used for audit or research?
10. Are costs per unit service reduced?

Healthfield identified l6 major evaluation questions.

NOTES
1. What is the impact of the technology on clinical management at 3 levels: individual
patient care, management of services, and resource management?
2. What is the impact on the roles, the organization of work and work satisfaction of
staff? What is the experience of working and living at the implementation sites?
3. Can the costs and benefits of such developments/technologies be valued?
4. Patient record systems and technologies: How useful and useable are they?
5. What is the relationship between electronic and paper records for the EPR sites in
respect of: availability of data, integrity, compliance with standards, volume of
paper generated and reduction in clerical activity?
6. What is the relationship between the technology and the general management of
the trust?
7. Anderson JG, Aydin CE, Jay SJ. Identified the following evaluation questions
and suggested methods.

DBA 1757
NOTES

NOTES
Amatayakul M.identified the following questions for evaluation

1) Does the system support the mission of the organization and provide for
continuity of care?
2) Does the system enable the business goals of the organization?
3) Does the CPR contribute to improved patient care and not just administrative
efficiencies?
4) Are end-users engaged in evaluating present systems and creating a vision for
the CPR? Do the end-users have an easy way to communicate issues and ideas
to management and information systems services?
5) Is there a vision of an information infrastructure to support continuous clinical
service?
6) Have knowledge requirements been assessed and new approaches to data
management taken?
7) Do present systems support the data content requirements of the new
transaction standards?
8) What planning has been done to support additional uniform data standards?
9) Do users see the value in using the system?
10) Does management understand the nature and timeframe for return on
investment?
11) Have resources been assigned to continuously monitor benefits realization?
12) Have the goals of service effectiveness, operational efficiency, and informational
empowerment been achieved?
NHS PROBE 2001. Evaluation Framework for NHS Electronic Patient Record
and Electronic Health Record. Evaluation Questions posed in 3 time frames and along 5
dimensions: strategy, operational, technical, financial and human.
Sample questions extracted

DBA 1757
NOTES

NOTES

DBA 1757
NOTES

NOTES

DBA 1757
NOTES

QUESTIONS
NOTES
5.3. a. Explain the guidelines for computerized patient record entries
5.3. b.What is a Electronic Medical Record?
5.3. c.Narrate the risks in computerized medical information system
5.3. d..Explain the Models used for evaluation of medical records
5.3.e.Explain the procedure to evaluate the complex health information system
SUMMARY
You have learned the guidelines for computerized patient record entries. You understood
the concept of Electronic Medical Record. You understood the various models commonly
used for evaluation. You learned the sample questions to be used for evaluation of complex
health information system.
EXERCISE
1. Visit a nearby corporate hospital and discuss with the employees how the
computerized system implemented is efficient in providing accurate , reliable and
timely information.
2 . Using internet, obtain the complete ASTM and HL7 guidelines for computerized
patient record system

DBA 1757
NOTES NOTES

NOTES NOTES

DBA 1757
NOTES NOTES

Hospital Information Management PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Hospital Information Management PDF

Transféré par

Droits d'auteur :

Formats disponibles

MBA

HOSPITAL INFORMATION SYSTEM

Centre for Distance Education

• Strategic Hospitality Management, Teare and Boer, Cassel Publishers, 1996.

Introduction to Healthcare Information - Fundamentals, system concepts, characteristics – Types of healthcare

UNIT II DATA SYSTEM IN HOSPITAL

UNIT III DATABASE MANAGEMENT

UNIT IV INFORMATION MANAGEMENT

Introduction-Functional –Types of administrative and clinical information system– Functional capabilities of

UNIT V DELIVERY NETWORK

1. Bipin C Desai. Introduction to Database design

1.1 FUNDAMENTALS IN HEALTHCARE INFORMATION 1

5.1 HEALTH CARE INDUSTRY: CHALLENGES

1.1 FUNDAMENTALS IN HEALTHCARE INFORMATION

1.1.2 Learning Objectives

Upon successful completion of this unit, you should be able to

1.1.3 Growth Of Healthcare Sector In India

1.1.3 (i). Health Administration System in India

1 ANNA UNIVERSITY CHENNAI

Organization of Health Care Administration in the Country Ministry of health and

1.1.3 (ii). Growing Healthcare Sector

The following table shows the % of middle class population in India

2 ANNA UNIVERSITY CHENNAI

SOURCE: CRIS Infac, 2005

However, India’s thriving economy is driving urbanization and creating an expanding

1.1.3 (iii).Importance of Healthcare

In addition to battling infectious diseases, India is grappling with the emergence of

3 ANNA UNIVERSITY CHENNAI

Paralleling the rise of disease is the emergence of a robust pharmaceutical industry in

1.1.3 (iv). Deteriorating Infrastructure

4 ANNA UNIVERSITY CHENNAI

healthcare. This is an extremely high proportion by international standards.3 Private firms

A widespread lack of health insurance compounds the healthcare challenges that

5 ANNA UNIVERSITY CHENNAI

6 ANNA UNIVERSITY CHENNAI

1.2 EVOLUTION OF HEALTHCARE INFORMATION SYSTEM

1.2.2 Learning Objectives

After reading this unit, you should be able to

7 ANNA UNIVERSITY CHENNAI

1.2.3 System And Its Characteristics

A group of interacting, interrelated, or interdependent elements forming a complex

1. A functionally related group of elements, especially:

Raw data to be processed to get Meaningful information

8 ANNA UNIVERSITY CHENNAI

I.S – an organizational & management solution based on I.T to a challenge posed by

1.2.3 (ii) System characteristics

The following are the basic characteristics of any system:

1.2.3 (iii). Relationship of system to one another

9 ANNA UNIVERSITY CHENNAI

1.2.4 Major Types Of Systems

Information systems support different types of decisions at different levels of the

10 ANNA UNIVERSITY CHENNAI

11 ANNA UNIVERSITY CHENNAI

Executive Support Systems (ESS) or Executive Information Systems (EIS) provide a

12 ANNA UNIVERSITY CHENNAI

The table 2 shows the characteristics of information processing in an organization.

13 ANNA UNIVERSITY CHENNAI

1.2.5 Healthcare Information Systems

1.2.5.(i) Fundamentals of healthcare information systems

14 ANNA UNIVERSITY CHENNAI

What we do have is the ability to re-design ineffective processes, implement evidence-

According to the Microsoft Corporation,

1.2.5.(ii) Need for Healthcare Information System