Vous êtes sur la page 1sur 236

Health Information Systems

Architectures and Strategies

Strategic Information Management in Hospitals


Manuscript 2010 chapter 6
August 2010
copyright by

W.J. ter Burg MSc


Department of Medical Informatics
Academic Medical Center
University of Amsterdam
Email:w.j.terburg@amc.uva.nl
and

Alfred Winter, University of Leipzig, Germany Reinhold Haux - University of


Braunschweig, Institute of Technology and of Hannover Medical School, Germany Elske
Ammenwerth, University for Health Sciences, Medical Informatics and Technology (UMIT)
in Hall, Austria
Birgit Brigl, German Federal Ministry of Finance Nils Hellrung, University of
Braunschweig, Institute of Technology and of Hannover Medical School, Germany
Franziska Jahn, University of Leipzig, Germany
WJPP ter Burg MSc et. al
Health Information Systems
1

Architectures of Hospital
Information Systems
Introduction
After having introduced health information systems in general we
will at first turn our attention to hospital information systems
We now take a closer look at what hospital information systems
look like. We will do that rather synthetically, meaning:
we will first look at all the detailed components a hospital information
system consists of,
and then we will explain how these components can be synthesized,
i.e. assembled in order to achieve that what users nowadays
experience as the hospital information system

WJPP ter Burg MSc et. al

Health Information Systems

Architectures of Hospital
Information Systems
We start discussing the kind of data, which has to be processed in
hospitals and then present hospital functions interpreting or
updating these data
We introduce typical information processing tools and typical
architectures first at the logical and then at the physical tool layer
of hospital information systems.
At each layer we explain how these tools can be assembled and
integrated for the better support of users

WJPP ter Burg MSc et. al

Health Information Systems

Architectures of Hospital
Information Systems
After this lecture, you should be able to answer the
following questions:

What kind of data has to be processed in hospitals?


What are the main hospital functions?
What are the typical information processing tools in hospitals?
What are the different architectures of HIS?
How can integrity and integration be achieved within HIS?

WJPP ter Burg MSc et. al

Health Information Systems

Architectures of Hospital
Information Systems
Domain Layer: data to be processed in Hospital
Entity types related to Patient Care (examples)
Typical entity types representing certain object classes and data
related to the patient and his or her histories:
Entity type

Descriptor of an instance of the represented object class

Case

mostly comprises a patients stay in a hospital from patient


admission to patient discharge or several ambulatory treatments
related to one disease; information about a case includes the case
identification number (CIN

Patient

is a person being subject of care; information about a patient


includes the patient identification number (PIN)

Order

is a request for a diagnostic, therapeutic or drug service, e. g., a


laboratory order or a radiological order

Diagnosis

is the identified cause or nature of a disease or medical condition

Note: we can express kind of data by entity types

WJPP ter Burg MSc et. al

Health Information Systems

Architectures of Hospital
Information Systems
Entity types related to Resources (examples)
A hospital must guarantee that all resources needed for patient
care are available continuously. The following resources are
necessary:
Entity type

Descriptor of an instance of the represented object class

Appointment

determines what persons have to be at a certain place at a given


time. Examples are appointment for patient admission,
examination or surgery.

Bed

must be managed according to its occupation.

Health care
professional

a health care professional who treats according to his or her


specialization (e. g. nephrology or pediatrics) patients with certain
diagnoses. Health care professionals are for example physicians
and nurses.

Drug

is a substance administered to a patient for treatment, diagnosis or


prevention

WJPP ter Burg MSc et. al

Health Information Systems

Architectures of Hospital
Information Systems
Entity types related to Administration (examples)
Besides information about resources, hospital administration
needs the following entity type:
Entity type

Descriptor of an instance of the represented object class

Patient record
archive

describes how and where the electronic or paper-based patient record can be
found.

Classification

consists of a set of classes summarizing concepts not to be distinguished


during analysis.

Classification of
diagnoses

e. g. the International Classification of Diseases (ICD).

Cost unit

information about a person or an institution responsible for bearing the costs or


a part of the costs for the services to be provided

WJPP ter Burg MSc et. al

Health Information Systems

Architectures of Hospital
Information Systems
Entity types related to Management (examples)
Management relates to the hospital as a whole and, thus, needs
compressed information about the hospitals operating. The
following entity types are necessary for management:
Entity type

Descriptor of an instance of the represented object class

Business
strategy

defines the hospitals long-term strategic goals

Strategic
information
management
plan

a strategic plan, which gives directives for the construction and development
of a hospital information system

Project

a unique undertaking that is characterized by management by objectives, by


restrictions with regard to available time and resources, and by a specific
project organization (DIN 69901)

Quality report

openly published report about a hospitals performance

WJPP ter Burg MSc et. al

Health Information Systems

Architectures of Hospital
Information Systems
Domain layer: Hospital Functions
We will now elucidate, how and where data about these entity
types are processed in hospitals.
We use enterprise functions to summarize classes of information
processing activities.
And since we focus on hospitals, we call them hospital functions
here, which can also be considered as representatives of
processes

WJPP ter Burg MSc et. al

Health Information Systems

Architectures of Hospital
Information Systems
We will present hospital functions and their interpreted and
updated entity types in greater detail, but we do not (yet) focus
on how they are typically supported by various computer-based
or non-computer-based information processing tools
We will focus on the following questions:
What are the main hospital functions that have to be supported by a
HIS?
What information is interpreted or updated by hospital functions?
Which functional aspects have to be considered when implementing
information processing tools?

WJPP ter Burg MSc et. al

Health Information Systems

10

Architectures of Hospital
Information Systems
Main enterprise function to be supported by a HIS:
Patient care
Supply and disposal management, scheduling and resource
allocation
Hospital administration
Hospital management
Research and education

WJPP ter Burg MSc et. al

Health Information Systems

11

Architectures of Hospital
Information Systems
Patient care:
Patient admission
Decision making, planning and organization of patient
treatment
Order entry
Execution of diacnostic, therapeutic and nursing procedures
Coding of diagnoses and procedures
Patient discharge

WJPP ter Burg MSc et. al

Health Information Systems

12

Architectures of Hospital
Information Systems
Patient admission:
Patient admission (short: admission) aims at recording and
distributing the patient demographics and insurance data as
well as medical and nursing data of the patient history
In addition, each patient must
becorrectly identified, and a
unique patient and case identifier
must be assigned

WJPP ter Burg MSc et. al

Health Information Systems

13

Architectures of Hospital
Information Systems
Patient admission
This hospital function can be decomposed as follows:

Appointment scheduling
Patient identification and checking for recurrent
Administrative admission
Medical admission
Nursing admission
Visitor and information service

WJPP ter Burg MSc et. al

Health Information Systems

14

Architectures of Hospital
Information Systems
Apointment scheduling:
The hospital must be able to schedule an appointment for a
patient's visit. In addition, unplanned patient admissions must be
possible (e.g., in case of emergencies)

WJPP ter Burg MSc et. al

Health Information Systems

15

Architectures of Hospital
Information Systems
Patient identification and checking for recurrent:
A unique patient identification number (PIN) must be assigned to each patient:

This PIN should be valid and unchangeable lifelong (i.e., the PIN should not be based
on changeable patients attributes such as the name)
The PIN is the main precondition for a patient-oriented combination of all information
arising during previous, recent as well as future hospitalizations

Before a PIN can be assigned, the patient must be correctly identified, usually
based on a health insurance card and on available administrative patient
master information (such as name, date of birth)
..

WJPP ter Burg MSc et. al

Health Information Systems

16

Architectures of Hospital
Information Systems
If the patient has already been in the hospital, she or he must be
identified as recurrent, and previously documented information
must be made available (such as previous diagnoses and
therapies).
If the patient is in the hospital for the first time, a new PIN must
be assigned.
In addition, the hospital must be able to distinguish different
cases or hospital stays of a patient. Therefore, in addition to the
PIN, a case identification number (CIN) is usually assigned (see
administrative admission).

WJPP ter Burg MSc et. al

Health Information Systems

17

Architectures of Hospital
Information Systems
Administrative admission:
Administrative admission starts following patient identification. It
creates a so-called case, being the aggregation of several contacts,
clustered according to specific clinical and/or organizational purposes of
the hospital
In case of inpatient treatment, a case summarizes the hospital stay from
patient admission until discharge
Each case is uniquely identified by its CIN. Important administrative
data such as insurance data, details about special services, patient's
relatives, admitting physician, and transfer diagnoses must be recorded
..
WJPP ter Burg MSc et. al

Health Information Systems

18

Architectures of Hospital
Information Systems
Some of the administrative data must be available to other
hospital functions through the help of certain organization media.
Administrative data form the backbone of information processing
In case of changes, patient data must be maintained and
communicated. If the admitting physician has communicated
relevant information (e.g., previous laboratory findings), this
information must be communicated to the responsible physician
in the hospital
..

WJPP ter Burg MSc et. al

Health Information Systems

19

Architectures of Hospital
Information Systems
Administrative admission is usually done either in a central
patient admission area or directly on the ward (e.g., during
emergencies or on the weekend)
Even in emergencies patient admission is necessary. At least
patient identification and checking for recurrent has to be
performed in order to assign a proper PIN and CIN. In these cases
a short version of administrative admission may be applicable
If the patient is unconscious and does not bear an identity card,
only a dummy name may be recorded to provide PIN and CIN. It
will be no problem to replace the dummy name by the correct
name later

WJPP ter Burg MSc et. al

Health Information Systems

20

Architectures of Hospital
Information Systems
Medical admission:
The responsible physician will carry out the medical admission. This
typically comprises the patient history (disease history, systems review,
social history, past medical history, family history, medication). Some of
this information may be collected from documents of the referring
physician and is taken to the hospital by the patient himself. Medical
admission is usually done on the ward
As a result of medical admission the admission diagnosis has to be stated
and to be coded according to ICD10
The basic patient history data have to be made available for other
hospital functions. For the patient history there may also be departmentspecific, (semi-) standardized data entry forms available
The collected information should be available during the whole stay
WJPP ter Burg MSc et. al

Health Information Systems

21

Architectures of Hospital
Information Systems
Nursing admission:
The responsible nurse will proceed with the nursing admission. This typically
comprises the introduction of the patient to the ward and the nursing history.
Nursing admission is usually done at the ward
Administrative data and the reason of hospitalization are already at her or his
disposal
For the nursing history there may be computer-based or department-specific,
(semi-) standardized data entry forms available. These may contain
information about the current diagnosis and therapy, orientation,
communication ability, social contacts, nutrition, mobility, personal hygiene,
and vital signs
The collected information should be available during the whole stay
WJPP ter Burg MSc et. al

Health Information Systems

22

Architectures of Hospital
Information Systems
Visitor and information services:
The hospital management must always have an overview of the recent bed occupation,
i.e., about the patients staying at the hospital.

This is, for example, important for


the clerks at the information desk,
who must be able to inform relatives
and visitors correctly, and also for
some general hospital management
statistics

WJPP ter Burg MSc et. al

Health Information Systems

23

Architectures of Hospital
Information Systems
Patient admission

Extract of the domain layer of the 3LGM based reference model describing
the enterprise function patient admission, its subfunctions and interpreted
and updated entity types.

WJPP ter Burg MSc et. al

Health Information Systems

24

Architectures of Hospital
Information Systems
Patient care:
Patient admission
Decision making, planning and organization of patient
treatment
Order entry
Execution of diacnostic, therapeutic and nursing procedures
Coding of diagnoses and procedures
Patient discharge

WJPP ter Burg MSc et. al

Health Information Systems

25

Architectures of Hospital
Information Systems
Decision making, planning and organization of patient
treatment
All clinical procedures of health care professionals must be
discussed, agreed upon, efficiently planned, and initiated. This
process is repeated each time new information is available

This hospital function can be decomposed as follows:


Decision making and patient information
Medical and nursing care planning

WJPP ter Burg MSc et. al

Health Information Systems

26

Architectures of Hospital
Information Systems
Decision making and patient information:
Responsible team members must decide upon the next steps
such as certain diagnostic or therapeutic procedures.
Depending on the complexity of a diagnostic or therapeutic
decision, they should be able to consult internal or external
experts
Staff members must be able to access all relevant patient data
specific to a situation, in addition to general clinical knowledge
supporting patient care

WJPP ter Burg MSc et. al

Health Information Systems

27

Architectures of Hospital
Information Systems
Medication prescription may be supported
knowledge about adverse drug events

by

providing

The patient should be involved in the decision-making process,


the consequences of the planned diagnostic or therapeutic
procedures should be explained, and his or her informed consent
must be documented as well
Decision making is a permanent enterprise function which is
triggered by new information about the patient
Decisions about clinical procedures must be documented

WJPP ter Burg MSc et. al

Health Information Systems

28

Architectures of Hospital
Information Systems
Medical and nursing planning
For each medical procedure (such as a radiological examination, an
operation or a chemotherapeutic treatment) as well as for each
nursing procedure, the type, extent, duration, and responsible person
have to be determined.
In nursing, care planning is documented in nursing care plans,
containing nursing problems, nursing goals, and planned nursing
procedures.
Care planning in cancer treatment is often performed in tumor board
reviews. I.e. a number of physicians who are experts in different
specialties (disciplines) review and discuss the medical condition and
treatment options of a patient
WJPP ter Burg MSc et. al

Health Information Systems

29

Architectures of Hospital
Information Systems
Decision making, planning and organization of patient
treatment

Extract of the domain layer of the 3LGM based reference model describing
the enterprise function decision making, planning and organization of
patient treatment, its subfunctions and interpreted and updated entity
types.

WJPP ter Burg MSc et. al

Health Information Systems

30

Architectures of Hospital
Information Systems
Patient care:
Patient admission
Decision making, planning and organization of patient
treatment
Order entry
Execution of diacnostic, therapeutic and nursing procedures
Coding of diagnoses and procedures
Patient discharge

WJPP ter Burg MSc et. al

Health Information Systems

31

Architectures of Hospital
Information Systems
Order entry
Diagnostic and therapeutic procedures must often be ordered at
specialized service units (e.g., laboratory, radiology, or
pathology).
These units execute the ordered procedures and communicate
the findings or results back to the ordering department
This hospital function can be decomposed as follows:
Preparation of an order
Appointment scheduling
WJPP ter Burg MSc et. al

Health Information Systems

32

Architectures of Hospital
Information Systems
Preparation of an order
Depending on the type of order, specimens that must be
unambiguously assigned to a patient are submitted (e.g., blood
sample)
Depending on the available service spectrum offered by a service
unit, which may be presented in the form of service catalogs, the
health care professional selects the appropriate service on an order
entry form Patient and case identification, together with relevant
information such as:

recent diagnoses,
the relevant questions,
the service ordered (e.g., laboratory, radiology), and
other comments (e.g., on special risks) are documented

..
WJPP ter Burg MSc et. al

Health Information Systems

33

Architectures of Hospital
Information Systems
An order should be initiated only by authorized persons.
When computer-based tools for order entry are used,
computerized decision support systems could alert the physician
in case of medication errors, e.g. when a medication is ordered
to which the patient is allergic
The order must quickly and correctly be transmitted to the
service unit. If a specimen is transferred, it must be guaranteed
that the order and the specimen can be linked to each other at
the service unit.
If necessary, modification to already transferred orders by the
ordering health care professional should be possible
WJPP ter Burg MSc et. al

Health Information Systems

34

Architectures of Hospital
Information Systems
Appointment scheduling
Depending on the type of order, the patients appointments
must be scheduled (e.g., in radiological units)
During
scheduling,
the
demands of all parties (e.g.,
ordering physician, service
unit, patient, transport unit)
must be fairly balanced

A paper-based order entry form for laboratory


testing

WJPP ter Burg MSc et. al

Health Information Systems

35

Architectures of Hospital
Information Systems
Order entry

Extract of the domain layer of the 3LGM based reference model describing
the enterprise function order entry, its subfunctions and interpreted and
updated entity types.

WJPP ter Burg MSc et. al

Health Information Systems

36

Architectures of Hospital
Information Systems
Patient care:
Patient admission
Decision making, planning and organization of patient
treatment
Order entry
Execution of diacnostic, therapeutic and nursing procedures
Coding of diagnoses and procedures
Patient discharge

WJPP ter Burg MSc et. al

Health Information Systems

37

Architectures of Hospital
Information Systems
Execution of diacnostic, therapeutic and nursing procedures
The planned diagnostic, therapeutic, or nursing procedures (such as
operations, radiotherapy, radiological examinations, medication)
must be
The hospital must offer adequate tools and resources (e.g., staff,
room, equipment) for the execution of the necessary procedures
It is important that changes in care planning that may be due to new
findings are promptly communicated to all involved units and
persons, enabling them to adapt to the new situation
..
WJPP ter Burg MSc et. al

Health Information Systems

38

Architectures of Hospital
Information Systems
All clinically relevant patient data (such as vital signs, orders, results,
decisions) must be recorded as completely, correctly, and quickly as
necessary. This supports the coordination of patient treatment
among all involved persons, and also the legal justification for the
actions taken
Data should be recorded as structured as possible, so to allow for
data aggregation and statistics, computerized decision support, or
retrieval of data
It is important that data can be linked by PIN and CIN, even when
data originate from different areas (such as ward, service unit,
outpatient unit)
..
WJPP ter Burg MSc et. al

Health Information Systems

39

Architectures of Hospital
Information Systems
Usually, the hospital has to fulfill a lot of different legal
reporting
(such
as
epidemiological
registers)
and
documentation requirements
The items to be documented depend partly on the documenting
unit and the documenting health care professional group (such
as documentation by health care professionals, documentation
in outpatient units or in operation rooms).
Clinical information should also be available for other functions
such as:
financial accounting, controlling, quality management, or
research and education Patient admission

WJPP ter Burg MSc et. al

Health Information Systems

40

Architectures of Hospital
Information Systems
Execution of diagnostic, therapeutic and nursing procedures
The planned diagnostic, therapeutic, or nursing procedures (such as
operations, radiotherapy, radiological examinations, medication)
must be
The hospital must offer adequate tools and resources (e.g., staff,
room, equipment) for the execution of the necessary procedures
This hospital function can be decomposed as follows:

Execution of diagnostic and therapeutic procedures


Execution of nursing procedures

WJPP ter Burg MSc et. al

Health Information Systems

41

Architectures of Hospital
Information Systems
Execution of diagnostic and therapeutic procedures
The planned diagnostic and therapeutic procedures:
must be executed,
all procedures must be documented,
findings and reports must be transmitted (as quickly as
necessary) back to the ordering unit and
presented to the responsible health care professional
They must be unambiguously assigned to the correct patient and
the responsible physician should be informed about new results,
and critical findings should be highlighted
..
WJPP ter Burg MSc et. al

Health Information Systems

42

Architectures of Hospital
Information Systems
The hospital function execution of diagnostic and therapeutic
procedures can be specialized for example:

execution
execution
execution
execution
execution
execution

WJPP ter Burg MSc et. al

of
of
of
of
of
of

operations,
irradiation,
chemotherapy,
radiological examinations,
lab examinations or
prophylaxis and medication

Health Information Systems

43

Architectures of Hospital
Information Systems
Execution of nursing procedures
The planned nursing procedures (concerning excretion, decubitus,
hair und nail care, skin care, wound treatment, body washing, oral
and dental care, nutrition and liquid balance, thrombosis) are
executed
All patient care procedures, their impact on the patient's health
status and changes to the care plan have to be documented
The responsible physician must be informed about therapy-relevant
facts

WJPP ter Burg MSc et. al

Health Information Systems

44

Architectures of Hospital
Information Systems
Execution
procedures

of

diacnostic,

therapeutic

and

nursing

Extract of the domain layer of the 3LGM based reference model describing
the enterprise function execution of diagnostic, therapeutic and nursing
procedures , its subfunctions and interpreted and updated entity types.

WJPP ter Burg MSc et. al

Health Information Systems

45

Architectures of Hospital
Information Systems
Patient care:
Patient admission
Decision making, planning and organization of patient
treatment
Order entry
Execution of diacnostic, therapeutic and nursing procedures
Coding of diagnoses and procedures
Patient discharge

WJPP ter Burg MSc et. al

Health Information Systems

46

Architectures of Hospital
Information Systems
Coding of diagnoses and procedures
The hospital must be able to document and code all diagnoses
stated and all medical procedures carried out in a correct,
complete, quick, and patient-oriented way.
These data are the basis for the hospital's billing. Diagnoses
and medical procedures are also used for controlling. In
addition, some of the data must be documented and
communicated due to legal requirements
..

WJPP ter Burg MSc et. al

Health Information Systems

47

Architectures of Hospital
Information Systems
Diagnoses and medical procedures are recorded and coded in a
standardized way (e.g., using the International Classification of
Diseases, ICD-1030 for diagnoses codes), and then processed.
Diagnoses and medical procedures should be at least partly
derivable from clinical documentation.
To support their documentation, adequate coding catalogs must
be offered and maintained, containing lists of typical diagnoses
and medical procedures relevant for a unit or a hospital

WJPP ter Burg MSc et. al

Health Information Systems

48

Architectures of Hospital
Information Systems
Coding of diagnoses and procedures

Extract of the domain layer of the 3LGM based reference model describing
the enterprise function coding of diagnoses and procedures, its subfunctions
and interpreted and updated entity types.

WJPP ter Burg MSc et. al

Health Information Systems

49

Architectures of Hospital
Information Systems
Patient care:
Patient admission
Decision making, planning and organization of patient
treatment
Order entry
Execution of diacnostic, therapeutic and nursing procedures
Coding of diagnoses and procedures
Patient discharge

WJPP ter Burg MSc et. al

Health Information Systems

50

Architectures of Hospital
Information Systems
Patient Discharge and Transfer to Other Institutions
When patient treatment is terminated, the patient is discharged
and then sometimes referred to other institutions (e.g., a
general practitioner, or a rehabilitation center)
Patient discharge and transfer to other institutions (short:
discharge) covers administrative, medical and nursing discharge
This hospital function can be decomposed as follows:
Administrative discharge and billing
Medical discharge and medical report writing
Nursing discharge and report writing

WJPP ter Burg MSc et. al

Health Information Systems

51

Architectures of Hospital
Information Systems
Administrative discharge and billing
The process of administrative patient discharge initiates final billing
and the fulfillment of legal reporting requirements (e.g., statistics on
diagnoses and procedures)
DRG (Diagnosis Related Groups) systems have been introduced for
patient billing in most of the industrial countries
That means, bills for patient treatment are no longer calculated
based on daily rates, but on the diagnosis related group in which a
patient case was classified. Diagnoses, procedures, patients age,
and some more criteria serve as an input for the calculation of a DRG

WJPP ter Burg MSc et. al

Health Information Systems

52

Architectures of Hospital
Information Systems
Medical discharge and medical report writing
Medical discharge entails completing of documentation and
writing of a
discharge report by the attending physician
The medical report includes:

the relevant diagnoses,


important findings,
therapeutic procedures,
the current patient state and
recommendations for further treatment

..
WJPP ter Burg MSc et. al

Health Information Systems

53

Architectures of Hospital
Information Systems
Medical discharge and medical report writing:
Medical discharge entails completing of documentation and
writing of a discharge report by the attending physician
The medical report includes:

the relevant diagnoses,


important findings,
therapeutic procedures,
the current patient state and
recommendations for further treatment

.....
WJPP ter Burg MSc et. al

Health Information Systems

54

Architectures of Hospital
Information Systems
The hospital must be able to transmit this and other information
(e.g., radiological images) to other institutions as quickly as
possible.
To speed up this process, a short report (i.e., physician's
discharge letter) is often immediately communicated to the
next institution, containing, for example, the diagnoses and
therapeutic treatments. It is then later followed by a more
detailed report.

WJPP ter Burg MSc et. al

Health Information Systems

55

Architectures of Hospital
Information Systems
Nursing discharge and medical report writing
Nursing discharge entails completing of documentation
and writing of a nursing report by the attending nurse.
The nursing report comprises, for example:
information about activity level,
diet, and
wound care

WJPP ter Burg MSc et. al

Health Information Systems

56

Architectures of Hospital
Information Systems
Patient Discharge and Transfer to Other Institution

Extract of the domain layer of the 3LGM based reference model describing
the enterprise function patient discharge and referral to other institutions,
its subfunctions and interpreted and updated entity types.

WJPP ter Burg MSc et. al

Health Information Systems

57

Architectures of Hospital
Information Systems
Main enterprise function to be supported by a HIS
Patient care
Supply and disposal management, scheduling and
resourch allocation
Hospital administration
Hospital management
Research and education

WJPP ter Burg MSc et. al

Health Information Systems

58

Architectures of Hospital
Information Systems
Supply and disposal
resource allocation:

management,

scheduling

and

The hospital must offer sufficient and well-organized resources


for patient care. This is true for:
wards (ward management),
outpatient units (outpatient management), and
service units (department management)

Efficient process organization is extremely important for


hospitals and it can be supported, for example, by providing
working lists for individual staff members, by issuing reminders
about appointments, or by visualizing actual process flow
..
WJPP ter Burg MSc et. al

Health Information Systems

59

Architectures of Hospital
Information Systems
The hospital information system must be able to support
communication between all persons involved in patient care
This comprises synchronous (e.g., telephone) and asynchronous
(e.g., blackboards, brochures, e-mail) communication.
Staff members must be able to be contacted within a prescribed
period of time
The hospital function supply and disposal management, scheduling
and resource allocation can be decomposed as follows:
Supply and disposal management
Scheduling and resource allocation
Human resourch management

WJPP ter Burg MSc et. al

Health Information Systems

60

Architectures of Hospital
Information Systems
Supply and disposal management
Supply and disposal of materials, food, drugs, and so on must be
guaranteed. All departments of the hospitals should be able to
order from up-to-date catalogs. The corresponding service units
(stock, pharmacy, and kitchen) must be able to deliver correctly
and on time
Supply and disposal management can be decomposed as follows:
Catering
According to their health status, patients have different nutritional
needs. It must be ensured that the patients are provided with the
right dietary food at the right time
..
WJPP ter Burg MSc et. al

Health Information Systems

61

Architectures of Hospital
Information Systems
Material and Medication Management
Nurses and doctors must be able to anticipate lacks of material
like medical strips, bandages or needles to order new material
from a central supplier in
Laundry Management
The hospital must permanently be supplied with linen, towels,
sterile scrubs, surgical masks etc
Management of Medical Devices
In addition to other resources, medical devices must be
registered and maintained according to legislation. Due
maintenance must be organized, documented and completed
WJPP ter Burg MSc et. al

Health Information Systems

62

Architectures of Hospital
Information Systems
Supply and disposal management

Extract of the domain layer of the 3LGM based reference model describing
the enterprise function supply and disposal management, its subfunctions
and interpreted and updated entity type.

WJPP ter Burg MSc et. al

Health Information Systems

63

Architectures of Hospital
Information Systems
Supply and disposal management, scheduling and resource
allocation
Supply and disposal management,
Scheduling and resource allocation,
Human resource management

WJPP ter Burg MSc et. al

Health Information Systems

64

Architectures of Hospital
Information Systems
Scheduling and Resource Allocation:
Various resources are needed for patient care, and resource
management comprises staff planning, bed planning, room
planning and device planning
All resource planning activities must be coordinated.
When procedures are scheduled, the demands of both the
service unit and the ordering unit with regard to scheduling the
appointment must be considered.
..
WJPP ter Burg MSc et. al

Health Information Systems

65

Architectures of Hospital
Information Systems
Request, reservation, confirmation, notification, postponement,
and cancellation must be supported
All involved staff members and patients should be informed
about the appointments
Postponements and cancellations should be communicated in
time to all involved persons
This hospital function can be decomposed into the functions
appointment scheduling, scheduling and resource planning with
the medical service unit and scheduling and resource planning
with the patient transport service

WJPP ter Burg MSc et. al

Health Information Systems

66

Architectures of Hospital
Information Systems
Scheduling and Resource Allocation

Extract of the domain layer of the 3LGM based reference model describing the
enterprise function scheduling and resource allocation, its subfunctions and interpreted
and updated entity type

WJPP ter Burg MSc et. al

Health Information Systems

67

Architectures of Hospital
Information Systems
Supply and disposal management, scheduling and resource
allocation
Supply and disposal management
Scheduling and resource allocation
Human resource management

WJPP ter Burg MSc et. al

Health Information Systems

68

Architectures of Hospital
Information Systems
Human resource management:
This contains all tasks for the development and improvement of the
productivity of staff. It comprises, for example, staff and position
planning, the staff register, staff scheduling, and staff payrol
This hospital function can be decomposed as follows:

Administration of human resource master data


Human resource planning
Work organization and time management
Payroll accounting
Administration of business trips and further training

WJPP ter Burg MSc et. al

Health Information Systems

69

Architectures of Hospital
Information Systems
Human resource management:

Extract of the domain layer of the 3LGM based reference model describing the
enterprise function human resources management , its subfunctions and interpreted
and updated entity types

WJPP ter Burg MSc et. al

Health Information Systems

70

Architectures of Hospital
Information Systems
Main enterprise function to be supported by a HIS
Patient care
Supply and disposal management, scheduling and resourch
allocation
Hospital administration
Hospital management
Research and education

WJPP ter Burg MSc et. al

Health Information Systems

71

Architectures of Hospital
Information Systems
Hospital administration
Hospital administration supports the organization of patient care and
guarantees the financial survival and the economic success of the
hospital
Hospital administration can be decomposed as follows:

Patient administration
Archiving of patient information
Quality management
Cost accounting
Controlling
Financial accounting
Facility management
Information management

WJPP ter Burg MSc et. al

Health Information Systems

72

Architectures of Hospital
Information Systems
Patient administration:
Patient administration comprises the administrative tasks in a
hospital dealing more or less immediately with patients.
Thus it is an aggregation of the subfunctions administrative
admission, patient identification and checking for recurrent,
visitor and information service and administrative discharge
and billing

WJPP ter Burg MSc et. al

Health Information Systems

73

Architectures of Hospital
Information Systems
Hospital administration

Patient administration
Archiving of patient information
Quality management
Cost accounting
Controlling
Financial accounting
Facility management
Information management

WJPP ter Burg MSc et. al

Health Information Systems

74

Architectures of Hospital
Information Systems
Archiving of patient information:
Relevant data and documents containing patient information must
be created, gathered, presented, and stored such that they are
efficiently retrievable during the whole process of patient
treatment.
The storage of these data and documents is primarily done in
patient records. Today, usually a mixture of paper-based and
computer-based patient records is used. Certain legal requirements
usually must be considered
This hospital function can be decomposed as follows:
Opening the patient record
Administration and allocation of patient records
Long term archiving
WJPP ter Burg MSc et. al

Health Information Systems

75

Architectures of Hospital
Information Systems
Opening the patient record:
Administrative admission triggers the opening of a patient
record. The patient record may be electronic or paper-based or
a mixture of both. For the filing formats of documents standards
have to be established and used

WJPP ter Burg MSc et. al

Health Information Systems

76

Architectures of Hospital
Information Systems
Administration and allocation of patient records:
A paper-based hospital archive must be able to manage patient
records and make them available upon request within a defined
time frame
The exact location of each record should be known (e.g., in
which archive, on which shelf)
Robot systems may store and gather paper-based records
Lending and return of records (e.g., for patients coming for
multiple visits) have to be organized, while respecting different
access rights that depend on the role of the health care
professionals in the process of patient care
WJPP ter Burg MSc et. al

Health Information Systems

77

Architectures of Hospital
Information Systems
Long term archiving:
After discharge of the patient, patient records must be archived
for a long time (e.g., for 10 or 30 years, depending on the legal
regulations)
The archive must offer enough space to allow the long-term
storage of patient records
Their authenticity and correctness can be proven more easily,
for example in case of legal action, when they are archived in
accordance with legal regulations

WJPP ter Burg MSc et. al

Health Information Systems

78

Architectures of Hospital
Information Systems

A paper-based hospital archive with robot system for storing


and gathering boxes filled with patient records

WJPP ter Burg MSc et. al

Health Information Systems

79

Architectures of Hospital
Information Systems
Archiving of patient information:

Extract of the domain layer of the 3LGM based reference model describing the
enterprise function archiving of patient information, its subfunctions and interpreted
and updated entity types

WJPP ter Burg MSc et. al

Health Information Systems

80

Architectures of Hospital
Information Systems
Hospital administration

Patient administration
Archiving of patient information
Quality management
Cost accounting
Controlling
Financial accounting
Facility management
Information management

WJPP ter Burg MSc et. al

Health Information Systems

81

Architectures of Hospital
Information Systems
Quality management:
Quality management comprises all activities of a health care
institution's management to assure and continuously improve
the quality of patient care
This includes setting goals, defining responsibilities, and
establishing and monitoring the processes to realize these
goals. This covers, for example, internal reporting containing
quality indices
..

WJPP ter Burg MSc et. al

Health Information Systems

82

Architectures of Hospital
Information Systems
Quality management requires information about patients and
treatments as well as knowledge about diagnostic and
therapeutic standards
This hospital function can be decomposed as follows:
Internal quality management assures a defined quality of all
processes and outcomes of the hospital. An internal reporting
system, which presents quality-related indicators, is also covered.
Medical, nursing and administrative guidelines may be defined,
stored and presented. There exists a structured complaint
management
Performance of legal notification
assurance must be completed
WJPP ter Burg MSc et. al

requirements

Health Information Systems

for

quality
83

Architectures of Hospital
Information Systems
Quality management:

Extract of the domain layer of the 3LGM based reference model describing the
enterprise function quality management, its subfunctions and interpreted and updated
entity types

WJPP ter Burg MSc et. al

Health Information Systems

84

Architectures of Hospital
Information Systems
Hospital administration

Patient administration
Archiving of patient information
Quality management
Cost accounting
Controlling
Financial accounting
Facility management
Information management

WJPP ter Burg MSc et. al

Health Information Systems

85

Architectures of Hospital
Information Systems
Cost accounting:
For controlling purposes, it is necessary to keep track of services,
their costs, and who has received them
Cost accounting usually investigates which costs incur (cost-type
accounting), where costs incur (cost center accounting) and for
what activities or services costs incur (cost unit accounting)
According to the accounting purpose, the time period to be
observed and the scope of the costs to be accounted have to be
defined
The results of cost accounting, i.e. key performance indicators,
serve as input for controlling
WJPP ter Burg MSc et. al

Health Information Systems

86

Architectures of Hospital
Information Systems
Cost accounting:

Extract of the domain layer of the 3LGM based reference model describing the
enterprise function cost accounting, its interpreted and updated entity types

WJPP ter Burg MSc et. al

Health Information Systems

87

Architectures of Hospital
Information Systems
Hospital administration

Patient administration
Archiving of patient information
Quality management
Cost accounting
Controlling
Financial accounting
Facility management
Information management

WJPP ter Burg MSc et. al

Health Information Systems

88

Architectures of Hospital
Information Systems
Controlling:
The hospital must be able to gather and aggregate data about
the hospital's operation in order to control and optimize it
This covers, for example, staff controlling, process controlling,
material controlling, and financial controlling.
In hospitals, for example, the number of patient cases, the
length of patients stays in the hospital and the case mix
index, which is calculated from the patients diagnosis related
groups (DRG), are key performance indicators serving as input
for controlling reports
WJPP ter Burg MSc et. al

Health Information Systems

89

Architectures of Hospital
Information Systems

Excerpt from a DRG scorecard, which is an important part of a


hospitals controlling report (in German).
WJPP ter Burg MSc et. al

Health Information Systems

90

Architectures of Hospital
Information Systems
Controlling:

Extract of the domain layer of the 3LGM based reference model


describing the enterprise function controlling and its interpreted and
updated entity types

WJPP ter Burg MSc et. al

Health Information Systems

91

Architectures of Hospital
Information Systems
Hospital administration

Patient administration
Archiving of patient information
Quality management
Cost accounting
Controlling
Financial accounting
Facility management
Information management

WJPP ter Burg MSc et. al

Health Information Systems

92

Architectures of Hospital
Information Systems
Financial accounting:
All the hospital's financial operations have to be systematically
recorded to meet legal requirements
Financial
accounting
comprises,
for
example,
debtor
accounting, credit accounting, and asset accounting. It needs
information from bills and creates new values for key
performance
The hospital must support general statistical analysis, for
example calculation and analysis of economic data

WJPP ter Burg MSc et. al

Health Information Systems

93

Architectures of Hospital
Information Systems
Financial accounting:

Extract of the domain layer of the 3LGM based reference model


describing the enterprise function financial accounting, its interpreted
and updated entity types

WJPP ter Burg MSc et. al

Health Information Systems

94

Architectures of Hospital
Information Systems
Hospital administration

Patient administration
Archiving of patient information
Quality management
Cost accounting
Controlling
Financial accounting
Facility management
Information management

WJPP ter Burg MSc et. al

Health Information Systems

95

Architectures of Hospital
Information Systems
Information management:

Extract of the domain layer of the 3LGM based reference model describing the
enterprise function Information management, its subfunctions and interpreted and
updated entity types
WJPP ter Burg MSc et. al

Health Information Systems

96

Architectures of Hospital
Information Systems
Hospital administration

Patient administration
Archiving of patient information
Quality management
Cost accounting
Controlling
Financial accounting
Facility management
Information management

WJPP ter Burg MSc et. al

Health Information Systems

97

Architectures of Hospital
Information Systems
Information management:
Information management plans the information system of an
enterprise and its architecture, directs its establishment and its
operation, and monitors its development and operation with respect
to the planned objectives
Different management levels have different perceptions and interests
This hospital function can be decomposed as follows:
Strategic information management
Tactical information management
Operational management
WJPP ter Burg MSc et. al

Health Information Systems

98

Architectures of Hospital
Information Systems
Strategic information management:
Strategic information management deals with the enterprise's
information processing as a whole and establishes strategies
and principles for the evolution of the information system
An important result of strategic management activities is a
strategic information management plan, which is aligned with
the hospitals business strategy
It includes the direction and strategy of information
management and the architecture of the enterprise information
system

WJPP ter Burg MSc et. al

Health Information Systems

99

Architectures of Hospital
Information Systems
Tactical information management:
Tactical information management deals with particular
enterprise functions or application components that are
introduced, removed, or changed
Usually these activities are done in the form of projects. Such
tactical information management projects are initiated by
strategic information management
The result of tactical information management projects is the
information system

WJPP ter Burg MSc et. al

Health Information Systems

100

Architectures of Hospital
Information Systems
Operational management:
Operational information management is responsible
operating the components of the information system

for

It cares for its smooth operation in accordance with the


strategic information management plan
Additionally, operational information management plans,
directs and monitors permanent services for the users of the
information system

WJPP ter Burg MSc et. al

Health Information Systems

101

Architectures of Hospital
Information Systems
Hospital management:

Extract of the domain layer of the 3LGM based reference model describing the
enterprise function hospital management, its interpreted and updated entity
types
WJPP ter Burg MSc et. al

Health Information Systems

102

Architectures of Hospital
Information Systems
Main enterprise function to be supported by a HIS
Patient care
Supply and disposal management, scheduling and resourch
allocation
Hospital administration
Hospital management
Research and education

WJPP ter Burg MSc et. al

Health Information Systems

103

Architectures of Hospital
Information Systems
Hospital management:
Hospital management decides on questions of fundamental
importance for the hospital development (hospital goals,
strategic decisions, personnel decisions and decisions about
budget, investments or key treatments)
Hospital management has to focus on high quality of patient
care taking into account economic as well as legal and other
requirements

WJPP ter Burg MSc et. al

Health Information Systems

104

Architectures of Hospital
Information Systems
Facility management:
Facility management comprises the management of buildings,
areas and utilities of the hospital and also influences key
performance indicators

Extract of the domain layer of the 3LGM based reference model describing the
enterprise function facility management, its subfunctions and interpreted and
updated entity types
WJPP ter Burg MSc et. al

Health Information Systems

105

Architectures of Hospital
Information Systems
Main enterprise function to be supported by a HIS
Patient care
Supply and disposal management, scheduling and resourch
allocation
Hospital administration
Hospital management
Research and education

WJPP ter Burg MSc et. al

Health Information Systems

106

Architectures of Hospital
Information Systems
The hospital function research and education can be
decomposed as follows:

Research management
Execution of clinical trials and experiments
Knowledge retrieval and literature management
Publishing and presentation
Education

WJPP ter Burg MSc et. al

Health Information Systems

107

Architectures of Hospital
Information Systems
Research management is executed in all organizational units of
the hospital which decide upon planning, monitoring and
directing research activities. This includes the documentation of
research activities as well as the management of third party funds
Experiments and clinical trials are important for the progress in
medicine because they update medical and nursing knowledge
Scientific staff must be supported in planning, executing and
analyzing studies and experiments
Planning and execution must conform to legal requirements; e.g.
patients have to be informed about chances and risks before they
can consent to take part in a clinical trial
WJPP ter Burg MSc et. al

Health Information Systems

108

Architectures of Hospital
Information Systems
Knowledge retrieval and literature management:
Scientific staff needs access to research-relevant information and
general medical knowledge. In addition, doctors and nurses must
be provided with specific medical knowledge
Publishing and presentation:
Scientific staff needs to prepare publications and presentations.
Therefore, central collections of both the hospitals relevant
publications and other literature need to be made available to them
and can be arranged according to year, institution, topic or person
Education:
Medical casuistics have to be made available for training and
education in medical professions. Furthermore, the organization and
execution of teaching and exams, e. g. by e-learning tools, have to
be supported
WJPP ter Burg MSc et. al

Health Information Systems

109

Architectures of Hospital
Information Systems
Research and education:

Extract of the domain layer of the 3LGM based reference model describing the
enterprise function research and education, its subfunctions and interpreted
and updated entity types.
WJPP ter Burg MSc et. al
Health Information Systems
110

Architectures of Hospital
Information Systems

Reference model of the domain layer


WJPP ter Burg MSc et. al

Health Information Systems

111

Architectures of Hospital
Information Systems
Logical tool layer: Application components (6.4)
After having looked at hospital functions in the previous section
we now describe information processing tools at the logical tool
layer of hospital information systems, i.e. the application
components supporting these functions
Each health institution uses a different set of computer-based and
non-computer-based application components (organizational
systems) to support its enterprise functions
However, in hospitals typical basic application components
supporting specific hospital functions can be identified

WJPP ter Burg MSc et. al

Health Information Systems

112

Architectures of Hospital
Information Systems
Logical tool layer: Application components (6.4)
After lecture, you should be able to answer the following
question:
What application components are used in hospitals, and what
are their characteristics?

Note that we refer to some of the components as XYZ information system (e.g., Laboratory
Information System). Although this sounds contradictorily to our definition of the term
information system we did so in order to integrate the popular names

WJPP ter Burg MSc et. al

Health Information Systems

113

Architectures of Hospital
Information Systems
Patient administration system
The patient administration system supports:

the administration of patients and their contacts at the hospital. Especially


for patient admission, discharge and billing of patients this application
component will be used
It must provide correct, complete and up-to-date administrative patient data
for all other application components
In addition, all other application components must be able to transmit
relevant administrative patient data (e.g., diagnoses) to the patient
administration system

Therefore the patient administration system can be regarded as the


center of the administrative memory of the hospital information system
WJPP ter Burg MSc et. al

Health Information Systems

114

Architectures of Hospital
Information Systems

Screen shot of a patient administration system showing the patient list of a department of
neurosurgery
in the background and a window for assigning an appointment to a patient in the front

WJPP ter Burg MSc et. al

Health Information Systems

115

Architectures of Hospital
Information Systems
Medical documentation system
The medical documentation system supports specific documentation
tasks and typically, it contains specialized modules for different
medical fields
Besides clinical documentation, the coding of diagnoses and
procedures is very important. Coding components must support the
easy search for suitable diagnosis and procedure classes and their
respective codes in classifications for a given medical field
Medical documentation is the basis for decision making and planning
of patient treatment. Hence the medical documentation system has to
support medical staff by providing medical knowledge, which should
be preselected using documented data about patients conditions
WJPP ter Burg MSc et. al

Health Information Systems

116

Architectures of Hospital
Information Systems

A screenshot of a medical documentation system showing a list of patient-related


documents on the left and an opened discharge letter on the right

WJPP ter Burg MSc et. al

Health Information Systems

117

Architectures of Hospital
Information Systems
Nursing management and documentation system
The nursing management and documentation system offers
similar features as the medical documentation system
The nursing management and documentation system has to
support the documentation of the so-called nursing process,
which mainly comprises nursing patient history, nursing care
planning with definition of problems, formulation of nursing aims,
and planning of nursing tasks, then execution of nursing tasks,
and evaluation of results
The nursing management and documentation system offers
support for using pre-defined nursing terminologies and nursing
classification such as NANDA, NIC and NOC
WJPP ter Burg MSc et. al

Health Information Systems

118

Architectures of Hospital
Information Systems

Screenshot of a nursing documentation system. On the left, it shows the selected nursing pathways for
the given patient. On the right, it shows the corresponding open tasks that now have to performed

WJPP ter Burg MSc et. al

Health Information Systems

119

Architectures of Hospital
Information Systems
Outpatient management system
Outpatient care means patient care during one or several short visits in
outpatient departments (clinics) in a hospital. In most cases, those visits are
related to previous or future inpatient stays in the same hospital
The outpatient management
documentation system

system

is

comparable

to

the

medical

Additionally many countries have different regulations for in- and outpatient
billing. Thus particular features are needed for billing in outpatient departments
These special requirements usually lead to specialized outpatient management
systems instead of using the medical documentation system in outpatient
settings

WJPP ter Burg MSc et. al

Health Information Systems

120

Architectures of Hospital
Information Systems

Screen shot of an application component for scheduling in an outpatient unit


WJPP ter Burg MSc et. al

Health Information Systems

121

Architectures of Hospital
Information Systems
Provider or physician order entry system
A provider or physician order entry system (POE) (computersupported POE systems are called CPOE) supports order entry.
This can comprise both order entry of diagnostic or therapeutic
procedures as well as ordering of drugs.
POE systems support formulation of the order, appointment
scheduling, printing of labels, and the communication of the order
to the service unit

WJPP ter Burg MSc et. al

Health Information Systems

122

Architectures of Hospital
Information Systems
Patient data management system (PDMS)
The patient data management system (PDMS) is specialized to automatically
monitor, store, and clearly present a vast amount of patient-related clinical
data in intensive care units
It also supports scoring (e.g., TISS, SAPS) and may offer features for
decision-support and various statistical analyses
Provide means for patient discharge and transfer to other wards or
institutions, e.g. a short summary of the therapy on the intensive care unit
should be created and communicated to the application components on the
ward
Software for a PDMS is sold both by specialized vendors and by vendors that
also offer automated monitoring tools
WJPP ter Burg MSc et. al

Health Information Systems

123

Architectures of Hospital
Information Systems
Operation management system
The operation management system supports operation planning and
operation documentation as a specialization of execution of diagnostic and
therapeutic procedures
It allows assigning of operation date and time, and therefore should be
available on the wards as well as in the offices and management units of
the operating rooms
The operation management system should be closely connected to the
medical documentation system

WJPP ter Burg MSc et. al

Health Information Systems

124

Architectures of Hospital
Information Systems
During each operation, a vast amount of data has to be
documented, including the members of the operating team, the
operative procedure, the date and time, duration of the operation,
materials (e.g., implants) used, and other necessary data to
describe the operation and its results
To avoid transcriptions, an operation management system should
therefore also provide supportive features for anesthesiologists in
an integrated way
The operation management system should also allow extensive
data analysis (e.g., operation lists for junior surgeons)

WJPP ter Burg MSc et. al

Health Information Systems

125

Architectures of Hospital
Information Systems
Radiology information system (RIS)
The radiology information system (RIS) offers features comparable
to those of the outpatient management systems, that is features
for:

registering patients,
appointment scheduling,
organization of examinations and staff (work-flow management),
provision of patient data and examination parameters,
creation of radiology reports,
documentation and coding of activities, and
statistics

WJPP ter Burg MSc et. al

Health Information Systems

126

Architectures of Hospital
Information Systems
A special feature is the close connection to the modalities:
The radiology information system typically provides a working list
(that is patient name and requested examination) for the modalities,
and
gets back a confirmation on
examination from the modalities

the

completion

of

radiologic

Due to these special features, software for RIS typically comes


from specialized vendors

WJPP ter Burg MSc et. al

Health Information Systems

127

Architectures of Hospital
Information Systems

Screenshot of a radiology information system showing all radiologic


documents
of one patient

WJPP ter Burg MSc et. al

Health Information Systems

128

Architectures of Hospital
Information Systems
Picture archiving and communication system (PACS)
By contrast, digital images are stored in the picture archiving and
communication system (PACS)
This application component allows:

the storage,
management,
manipulation and
presentation of large amounts of image data and
communication from the storage media to the attached workstations
for the diagnosing specialists or for the ordering departments

.....
WJPP ter Burg MSc et. al

Health Information Systems

129

Architectures of Hospital
Information Systems
Quick communication may require a prefetching strategy to retrieve
image data from slower storage devices and to provide it at faster
devices well in advance to the situation they will be needed
RIS and PACS should be closely connected. They should also have a
tight connection to:

the patient administration system,


medical documentation system,
provider/physician order entry system (POE), and
the patient data management system,

in order to allow quick access to reports and imaging pictures from


every unit
WJPP ter Burg MSc et. al

Health Information Systems

130

Architectures of Hospital
Information Systems

Screen shot from a PACS application component, presenting different images of


a patient

WJPP ter Burg MSc et. al

Health Information Systems

131

Architectures of Hospital
Information Systems
Laboratory information system (LIS)
During execution of lab examinations, specimens of patients (e.g.,
blood sample, tissue sample) are used. Appointments are
therefore not necessary
Depending on the type of laboratory, different examination
technologies are used (e.g., chemical analysis of blood samples,
microscopical analysis, and tissue samples)
..

WJPP ter Burg MSc et. al

Health Information Systems

132

Architectures of Hospital
Information Systems
The laboratory information system (LIS) supports:
the management of the whole procedure of analysis:
the receipt of the order and the sample,
the distribution of the sample and the order to the different analytical
devices,
the collection of the results,
the technical and clinical validation of results,
the communication of the findings back to the ordering department,
as well as
general quality management procedures

..
WJPP ter Burg MSc et. al

Health Information Systems

133

Architectures of Hospital
Information Systems
The laboratory information system, therefore, should be closely
connected to:

the medical documentation system,


outpatient management system,
provider/physician order entry system (POE), and
the patient data management system (PDMS)

Software for laboratory information systems are usually also sold


by specialized vendors

WJPP ter Burg MSc et. al

Health Information Systems

134

Architectures of Hospital
Information Systems
Enterprise resource planning system
The enterprise resource planning system (often: ERP system)
enables a hospital to manage its financial, human and material
resources
One major goal is the documentation and billing of all accountable
services.
It thus supports hospital functions such as:

controlling,
financial accounting,
facility management,
human resources manage-ment,
quality management and
supply and disposal management

WJPP ter Burg MSc et. al

Health Information Systems

135

Architectures of Hospital
Information Systems
Data warehouse system
A data warehouse system contains data which have been
extracted from other application components
The data have been transferred and aggregated into a suitable
format and then actively loaded into the data warehouse (pushprinciple)
A specific request on the data will only access data already
loaded into the data warehouse
..
WJPP ter Burg MSc et. al

Health Information Systems

136

Architectures of Hospital
Information Systems
There are two major fields of application for data warehouse
systems in hospitals they can either be used for hospital
management or for research
A data warehouse system can help to answer these questions by
pooling management-relevant data from other systems (e.g. ERP
and CPOE) and providing means for analyzing these data by data
mining techniques
A data warehouse system supporting hospital management is
often called business intelligence system
Note: There is an ISO standard (ISO TR 22221) on Good principles and practices for a clinical data
warehouse (CDW) which provides implementation guidance for data warehouses in HIS

WJPP ter Burg MSc et. al

Health Information Systems

137

Architectures of Hospital
Information Systems
Document archiving system
The document archiving system offers long-term archiving of
patient-related and other data and documents based on sustainable
standardized data formats, document formats and interfaces.
The system also provides standardized indexing of document
content and regular updates of storage media

The document archiving system is typically closely linked to


all application components that generate data and
documents which it has to store for a long time. It gets
copies of data and documents from those components
..
WJPP ter Burg MSc et. al

Health Information Systems

138

Architectures of Hospital
Information Systems
Typically, document archiving systems can archive not only textrelated documents, but also images, videos and other multimedia
data
All these documents may be stored using established non-proprietary
industry standards like ASCII, PDF, XML, TIFF, JPEG and MPEG, and
DICOM
In addition, there exists the document format CDA (Clinical Document
Architecture), which can be used for structuring clinical documents
Archived XML data (such as CDA) should include the corresponding
Document Type Definitions (DTD) in form of XSD (XML schema
definition), and the layout specification of an XML document in form
of XSL (eXtensible Stylesheet Language) files
WJPP ter Burg MSc et. al

Health Information Systems

139

Architectures of Hospital
Information Systems
Other computer-based application components
In addition to the computer-based application components
introduced so far, we can usually find many other, often
department-specific application components in a hospital
For example:

Pharmay information system


Cardiovascular information system (CVIS)
Decision support system
Pathology information system
.

WJPP ter Burg MSc et. al

Health Information Systems

140

Architectures of Hospital
Information Systems
Other computer-based application components
Application component

Description

Blood bank management


system

supports blood donor services, blood analyses, administration of blood bottles.

Cardiovascular information
system (CVIS)

provides many features of a clinical information system and a radiology information


system while tailoring the special needs of a cardiology department.

Decision support system

a knowledge-based system which assists a doctor in finding the right diagnosis or


treatment for a specific patient

Dialysis information system

provides many features of a clinical information system while tailoring the special needs of
a dialysis department, has interfaces to hemodialysis machines.

Digital dictation system

offers features for digital voice recording and speech recognition, is often integrated into
medical information systems and supports report, finding and letter writing.

Oncology information system

provides many features of a clinical information system while tailoring the special needs of
an oncology department.

Orthopedics information
system

provides many features of a clinical information system while tailoring the special needs of
an orthopedics department, can include a computer-aided design (CAD) system for
transplant planning.

Pathology information system

has similar features as a laboratory information system, e. g. receiving orders, writing


reports.

Pharmacy information system

supports the workflow in the pharmacy department: receiving drug orders, managing the
drug stock, distributing drugs throughout the hospital.

Teleradiology system

enables evaluations of radiological images from (external) radiologists remote workplaces


Health
Information
141
and may be closely
connected
to RISSystems
and PACS.

WJPP ter Burg MSc et. al

Architectures of Hospital
Information Systems
Converging technologies
Until now we focused on classical application components, i.e.
software installations in HIS primarily supporting the hospital
functions
But there are more and more installations of software in hospitals,
which are primarily controlling medical devices
Hence medical devices can increasingly be considered to be
application components and in many cases to be specialized
medical documentation systems
..
WJPP ter Burg MSc et. al

Health Information Systems

142

Architectures of Hospital
Information Systems
Consequently they do not only provide information (e.g., findings
and images) via respective interfaces, but need information from
other application components (e.g., patient, case, order) as well
This close interconnection is often referred to by the term
converging technologies
Due to the considerable risks for patients safety reasonable care
has to be exercised when integrating these converging
technologies into the computer-supported part of HIS

WJPP ter Burg MSc et. al

Health Information Systems

143

Architectures of Hospital
Information Systems
Clinical Information System (CIS) and Electronic Patient
Record System (EPR) as Comprehensive Application
Components
Not every hospital information system contains a medical
documentation system, an outpatient management system, a
nursing management and documentation system or a CPOE system
as separate, identifiable application component
Instead, these components are often closely integrated modules of
a so-called clinical information system (CIS)
CIS are also often called electronic patient record systems (EPR
systems)
WJPP ter Burg MSc et. al

Health Information Systems

144

Architectures of Hospital
Information Systems
The electronic patient record EPR, i.e. the electronic health record
(EHR) in a hospital, is a complete or partial patient record stored on
an electronic storage medium.
Given this definition:
Every computer-based application component supporting execution
of diagnostic and therapeutic procedures or other subfunctions of
patient care (e.g., medical documentation system, outpatient
management system, nursing management and documentation
system, PDMS) contains at least a partial EPR

WJPP ter Burg MSc et. al

Health Information Systems

145

Architectures of Hospital
Information Systems
In a CIS, these partial EPRs are often integrated and made available
to the professionals from all areas of a hospital to provide one
harmonized view on the data of a patient.
Because of this harmonized view the term electronic patient record
system (EPR system) as a particular application component has
become quite common

WJPP ter Burg MSc et. al

Health Information Systems

146

Architectures of Hospital
Information Systems
Typical non-computer-based application components
Non-computer-based application components contain rules and
plans regarding how and in which context what non-computerbased physical tools shall be used in order to support particular
enterprise functions
Typical application components that are still paper-based in a larger
percentage of hospitals comprise, for example:
the patient chart,
the patient record, and
clinical text books and knowledge sources
WJPP ter Burg MSc et. al

Health Information Systems

147

Architectures of Hospital
Information Systems
The paper-based patient chart system
The patient chart system supports:
documentation and presentation of body temperature,
blood pressure, pulse, and other vital signs
orders to other health care professionals such as drug orders, orders of
examinations,
order for special dietary,
describing executed procedures (e.g., drug is given, examination is
ordered) as well as findings (e.g., relevant lab values) and
other clinical information

WJPP ter Burg MSc et. al

Health Information Systems

148

Architectures of Hospital
Information Systems

The patient chart

The paper-based patient record

WJPP ter Burg MSc et. al

Health Information Systems

149

Architectures of Hospital
Information Systems
The paper-based patient record system
The paper-based patient record system, comprising a paper file and
the organizational rules which papers have to be collected here by
whom
The paper-based patient record system serves as:

a collection of all documents that are either available only in paper-based


form (such as the patient chart), or

that are printed out by computer-based application components to support


easier access to relevant data (such as print-out of new findings)

..
WJPP ter Burg MSc et. al

Health Information Systems

150

Architectures of Hospital
Information Systems
Logical tool layer: Integration of application components
As has been seen, HIS typically comprise various application components
that need to be integrated to achieve high quality of information processing

Integration in general describes a union of parts making a whole, which as


opposed to it parts displays a new quality

Integration additionally stands for the actions to be taken in order to achieve this
property and thus has a behavioral perspective

To achieve a high level of integration within a HIS the components need to


be able to work together, that means they need to be interoperable
Interoperability in general is the ability of two or more components to
exchange information and to use the information that has been exchanged

WJPP ter Burg MSc et. al

Health Information Systems

151

Architectures of Hospital
Information Systems
Hospital information systems at different hospitals usually look
different. But there are some criteria helping to categorize the
respective architectures. We will first introduce a taxonomy of
architectures of HIS, providing criteria at the logical tool layer
Regardless of what kind of architecture has been chosen for a
hospital information system, integrity, i.e. the correctness of data,
has to be ensured

WJPP ter Burg MSc et. al

Health Information Systems

152

Architectures of Hospital
Information Systems
After this lecture, you should be able to answer the
following questions:
How can architectures of HIS be categorized?
What differs integrity from integration?
What standards and technologies are available to support integration
of HIS?
How can integration efforts be reduced by decreasing the variety of
application components in a HIS?

WJPP ter Burg MSc et. al

Health Information Systems

153

Architectures of Hospital
Information Systems
Taxonomy of Architectures at the Logical Tool Layer
The architecture of an information system describes its
fundamental organization, represented by its components, their
relationships to each other and to the environment, and the
principles guiding its design and evolution
The components of a hospital information system comprise:
hospital functions,
business processes, and
information processing tools

WJPP ter Burg MSc et. al

Health Information Systems

154

Architectures of Hospital
Information Systems
Architectural styles at the logical tool layer of the computersupported part of HIS are characterized by
number of databases being used to store (especially patient related)
data;
number of application components used to support the hospital
functions;
number of different software products and vendors used to install the
application components;
the patterns of communication links between the application
components used
the types of integration, which could be achieved

..
WJPP ter Burg MSc et. al

Health Information Systems

155

Architectures of Hospital
Information Systems
Number of databases: central vs distributed
Application components of HIS may store data about certain
entity types persistently
Usually a database is used for this. We will use the number of
databases storing data in a HIS as the basis to distinguish
possible data distribution styles at the logical tool layer of HIS:
the DB1 style
the DBn style

WJPP ter Burg MSc et. al

Health Information Systems

156

Architectures of Hospital
Information Systems
The DB1 style
If a HIS (or its sub-information system) comprises only one database to store
all patient-related data, we call this the DB1 style. This single database is
often called the central database

The precondition for the DB1 style is that all computer-based


application components store their data only in the central database.
This is only possible when the database schema of the central
database is known, together with the methods that are available to
access and store data there
This is usually only the case if the software products of the
application components originate from the same vendor

WJPP ter Burg MSc et. al

Health Information Systems

157

Architectures of Hospital
Information Systems
The DB1 style therefore can be found mostly in HIS or in its sub-information systems where
application components are used, that are based on homogeneous software products
(either self-developed or purchased from the same vendor

If
application
components
from different vendors are
used, the so-called DBn style
can usually be found

(DB1, ACn) architecture with multiple computer-based


application components, using 3LGM symbols

WJPP ter Burg MSc et. al

Health Information Systems

158

Architectures of Hospital
Information Systems
The DBn style
In HIS, which are based on commercial software components of
many different vendors, we can usually find the DBn style
This means that several application components store data about
certain entity types persistently and contain their own databases
As a consequence of this style, patient-related data are stored
redundantly in different application components
..

WJPP ter Burg MSc et. al

Health Information Systems

159

Architectures of Hospital
Information Systems
In this architecture, great emphasis has to be placed on the
consistency of redundant data
For example, the architecture must define which system is the
responsible source for which data elements
In the case of different computer-based application components
being not at all connected, and data storage is organized
completely independently, there is no way to guarantee integrity
and consistency of data
This HIS style usually indicates that information management has
to be improved
WJPP ter Burg MSc et. al

Health Information Systems

160

Architectures of Hospital
Information Systems
The DBn style

DBn style with multiple computer-based application components,


each with its own database system

WJPP ter Burg MSc et. al

Health Information Systems

161

Architectures of Hospital
Information Systems
Mixed DB1/DBn style
In practice you will hardly find HIS with pure DB1 style. It is hardly
possible to stop implementation of further application
components with integrated databases.
Hence even if a considerable part of these HIS is DB 1 styled, they
are in fact DBn styled
We will refer to this style as a mixed DB1/DBn style

WJPP ter Burg MSc et. al

Health Information Systems

162

Architectures of Hospital
Information Systems
Number of Application Components: Monolithic vs. Modular
In the simplest case, the overall HIS consists of only one
computer-based application component, which supports most of
the enterprise functions.
This application component looks like the one rock, on which the
whole hospital rests. Respective HIS are commonly called
monolithic.
We will refer to this style by the string AC 1
DB1, AC1 architecture

WJPP ter Burg MSc et. al

Health Information Systems

163

Architectures of Hospital
Information Systems
One application component is usually not sufficient to support the
different hospital functions
More and more specialized
components as introduced

computer-based

application

This leads to architectures with a multiplicity of application


components, which can be denoted by ACn and are called
modular architectures

WJPP ter Burg MSc et. al

Health Information Systems

164

Architectures of Hospital
Information Systems
However, it can also be a DB1 architecture, for example: the RIS,
the LIS and the outpatient management system share one single
database management system in a certain application
component
This (sub-) information system could be described by (DB1, ACn)

(DB1,
ACn)
architecture
with
multiple
computer-based application components

WJPP ter Burg MSc et. al

Health Information Systems

165

Architectures of Hospital
Information Systems
Number of software products and vendors: all-in-one vs
best-off-breed
The terms homogeneity and heterogeneity are commonly
used to describe, whether a HIS consists of somehow similar
components or very different ones
A practical measure is the number of software products installed
or the number of vendors delivering these products to a HIS

WJPP ter Burg MSc et. al

Health Information Systems

166

Architectures of Hospital
Information Systems
We denote a homogenous (sub-) HIS, i.e. a (sub-) HIS with
software from only one vendor as V1.
Consequently, independent of the number of application
components, V1-HIS use only software products that all come from
the same vendor.
On the contrary, heterogeneous HIS comprise software from
several vendors; they are denoted as Vn.

WJPP ter Burg MSc et. al

Health Information Systems

167

Architectures of Hospital
Information Systems
We denote a homogenous (sub-) HIS, i.e. a (sub-) HIS with
software from only one vendor as V1
Consequently, independent of the number of application
components, V1-HIS use only software products that all come from
the same vendor
On the contrary, heterogeneous HIS comprise software from
several vendors; they are denoted as Vn

WJPP ter Burg MSc et. al

Health Information Systems

168

Architectures of Hospital
Information Systems
An (ACn, Vn) architecture where the different application
components are based on software from different vendors is
commonly denoted as best-of-breed, pointing to the fact that
the hospital combines the best software products from different
vendors
This best-of-breed architecture is typically DB n
On the contrary, a monolithic (AC1, V1) architecture and even an
(ACn, V1) architecture emphasizes that the hospital selected only
one product from only one vendor to support as many hospital
functions as necessary
This homogeneous architecture is also called all-in-one
WJPP ter Burg MSc et. al

Health Information Systems

169

Architectures of Hospital
Information Systems
Communication pattern: Spaghetti vs Star
Application components being part of an ACn architecture have to
be connected to achieve integration
Two different communication patterns:
Spaghetti styled communication pattern
Star styled communication pattern

WJPP ter Burg MSc et. al

Health Information Systems

170

Architectures of Hospital
Information Systems
Spaghetti-styled communication pattern
One way would be to directly connect those application
components that need to exchange certain patient-related data
Consequently, when connecting several application components,
this will lead to an increasing number of bidirectional
communication interfaces. As the number of application
components rises, the number of interfaces grows nearly
exponentially
This architecture is called spaghetti style
We
denote
architectures
with
communication pattern as CPn
WJPP ter Burg MSc et. al

this

Health Information Systems

spaghetti-styled

171

Architectures of Hospital
Information Systems
Spaghetti architectural style

(DBn, ACn, Vn, CPn) architecture with multiple computer-based application


components with several bidirectional communication interfaces.

WJPP ter Burg MSc et. al

Health Information Systems

172

Architectures of Hospital
Information Systems
Star-styled communication pattern
To reduce the large number of interfaces, one can use smarter
methods and tools to organize and realize the interoperability of
application components i.e., middleware approaches
For example, most hospital information systems following the DB n
style use a communication server
By using a communication server, no direct interfaces between
application components are needed
Note that star architectures do not necessarily contain communication servers, as the center of the
star may also be a database. Consequently (DB1, ACn) architectures will also be CP1 architectures

WJPP ter Burg MSc et. al

Health Information Systems

173

Architectures of Hospital
Information Systems
The number of interfaces that must be managed can
consequently be low, ideally only n interfaces exist for n
application components
We call this style star architecture and denote it as CP1
We may call a service-oriented architecture with one application
component serving as a broker or as a service bus a CP1
architecture as well.
But for AC1 this concept obviously does not make sense and
neither CP1 nor CPn should be applied.

WJPP ter Burg MSc et. al

Health Information Systems

174

Architectures of Hospital
Information Systems
Star architectural style

(DBn, ACn, Vn, CP1) architecture with multiple computer-based application


components connected by a specific application component

WJPP ter Burg MSc et. al

Health Information Systems

175

Architectures of Hospital
Information Systems
Integrity
In a HIS, integrity in the broadest sense is understood as to mean the
correctness of the data stored in the HIS
Important conditions for integrity are:

Object identity,
referential integrity and
consistency

WJPP ter Burg MSc et. al

Health Information Systems

176

Architectures of Hospital
Information Systems
Object identity
Condition of an information system where the representation of
every entity is uniquely identifiable
Object identity comes from object-oriented programming and means
that an object has an existence that is independent of its value.
Thus, two objects may look the same, that is, have the same value,
but be different

WJPP ter Burg MSc et. al

Health Information Systems

177

Architectures of Hospital
Information Systems
Experience has shown that object identity of the entity type
patient can be guaranteed only when every patient receives a
unique number, the patient identification number (PIN)
The PIN should have no internal meaning. That is, it is created
continuously and is usually numerical
Similar actions should be taken for the entity type case. A case
identification number (CIN), which should also have no apparent
meaning, should be assigned for every case.
Note: a CIN cannot change, as opposed to the PIN, whose relation to a patient must
be corrected after a misidentification has taken place

WJPP ter Burg MSc et. al

Health Information Systems

178

Architectures of Hospital
Information Systems
Assigning a PIN and a CIN to a patient is part of the hospital
function patient identification and checking for recurrent, which is
a subfunction of patient admission
Since PIN and CIN are assigned during patient admission, only
one admission has to be performed and only one PIN has to be
assigned to the patient during his or her visit.
This works well, if there is exactly one dedicated application
component supporting patient admission, namely the patient
administration system

WJPP ter Burg MSc et. al

Health Information Systems

179

Architectures of Hospital
Information Systems
Referential integrity
Correct assignment of entities, for example the assignment of cases
to a certain patient, or of results to a case. A precondition is object
identity. Referential integrity is an important condition for integrity
within health information systems
Ensuring object identity for patients and cases is the basic duty of a HIS,
regardless of whether it is computer-supported or not
Without object identity there is no referential integrity, and without
referential integrity it cannot be ensured that results can be related back to
the correct patient
Without the correct distribution of the PIN and CIN, the installation of
communication networks and computer systems is practically useless
WJPP ter Burg MSc et. al

Health Information Systems

180

Architectures of Hospital
Information Systems
Referential integrity
Object identity is
referential integrity.

needed

for

Thus findings and orders need


strict
appliance
of
unique
identifiers as well as patient and
case

Assignment of findings to orders and to cases, and of those


cases to a particular patient, in a UML based data model

WJPP ter Burg MSc et. al

Health Information Systems

181

Architectures of Hospital
Information Systems
Consistency
Situation where redundant copies of data representing the same
information about one particular object are identical. Consistency of data
is an important condition for integrity within health information systems
In DBn styled information systems patient data and data of other objects are often
stored redundantly, i.e. there are copies of data representing the same information
about one particular object
However, if the data are not identical and thus representing contradictory
information, we call these data inconsistent, i.e. duplicates of the same data.
Transaction management tries to make sure that data are consistent we then talk
of replicates, meaning that copies of data are automatically held consistent. In DB1
architectures, no redundant data exist as all data are unicates

WJPP ter Burg MSc et. al

Health Information Systems

182

Architectures of Hospital
Information Systems
Consistency
Situation where redundant copies of data representing the same
information about one particular object are identical. Consistency
of data is an important condition for integrity within health
information systems
However, if the data are not identical and thus representing
contradictory information, we call these data inconsistent

WJPP ter Burg MSc et. al

Health Information Systems

183

Architectures of Hospital
Information Systems
In DBn styled information systems patient data and data of other
objectsare often stored redundantly, i.e. there are copies of data
representing the same information about one particular object
Transaction management tries to make sure that data are
consistent we then talk of replicates, meaning that copies of
data are automatically held consistent.
In DB1 architectures, no redundant data exist as all data are
unicates

WJPP ter Burg MSc et. al

Health Information Systems

184

Architectures of Hospital
Information Systems
Types of integration
Even if the application components at the logical tool layer are
linked (or networked) together through interfaces in order to
cooperate, there may be different types of integration
A union of parts making a whole, which - as opposed to its parts displays a new quality. We speak of integrated health information
system if we want to express that it is a union that represents
more than just a set of independent components
To achieve this
interoperable

WJPP ter Burg MSc et. al

integration,

the

components

Health Information Systems

need

to

be

185

Architectures of Hospital
Information Systems
Different types of integration on the logical tool layer are:

data integration,
semantic integration,
access integration,
presentation integration,
contextual integration, and
process integration

On the physical tool layer, physical integration is important

WJPP ter Burg MSc et. al

Health Information Systems

186

Architectures of Hospital
Information Systems
Data integration
Data integration is obtained in a hospital information system when
data that have been recorded are available wherever they are
needed, without having to be reentered
Thus each data item needs to be recorded, changed, deleted, or
otherwise edited just once, even if it is used in several application
components
Note: In DBn architectures, communication interfaces in the computer-supported part of
HIS are required, and ways to print out data or scan data in order to provide
communication between the computer-based and the non-computer-based part of HIS

..
WJPP ter Burg MSc et. al

Health Information Systems

187

Architectures of Hospital
Information Systems
For example:
Assume your child was treated in the pediatrics department and a detailed
patient history was collected and saved.
Now, the child has to go for a hearing examination at the ear, nose, and
throat department of the same hospital.
If the patient history needs to be collected again because the document
from the pediatrics department cannot be accessed, there is no data
integration.
Data integration is possible even when data items are stored redundantly

WJPP ter Burg MSc et. al

Health Information Systems

188

Architectures of Hospital
Information Systems
Semantic integration
Condition of an information system where different application
components use the same system of concepts, i.e. they interpret
data the same way, or where different systems of concepts used
by application components are mapped to each other
Semantic integration between different application components
using different systems of concepts can be achieved by
implementing a mapping for the mutual translation of the
concepts between the different application components, or by
using the same system of concepts
..
WJPP ter Burg MSc et. al

Health Information Systems

189

Architectures of Hospital
Information Systems
Semantic integration can be supported
dictionaries (MDDs) elegantly and thoroughly.

by

medical

data

MDDs are central catalogs of medical concepts and terms that:


offer the possibility of representing the semantic relationships among
all data stored in a hospital information system, and
are linking that local vocabulary to internationally standardized
nomenclatures and knowledge sources

MDDs can be independent application components or part of


existing application components
..
WJPP ter Burg MSc et. al

Health Information Systems

190

Architectures of Hospital
Information Systems
For example:
When the sending application component uses the abbreviation GOT for
a lab parameter, but the receiving application does not know this code but
uses ASAT instead for the same concept, then semantic integration is
violated

WJPP ter Burg MSc et. al

Health Information Systems

191

Architectures of Hospital
Information Systems
Access integration
Condition of an information system where the application
components needed for the completion of a certain task can be
used where they are needed
For example:
The patient administration system is needed for patient admission, then
the patient administration system should be accessible at all workstations
where patient admission has to take place: central admission areas,
wards, outpatient units, the radiological outpatient unit, emergency
department, etc

WJPP ter Burg MSc et. al

Health Information Systems

192

Architectures of Hospital
Information Systems
Presentation integration
Condition of an information system where business processes are
effectively supported by a set of interacting application
components
For example:
Different application components at a workstation should display the
name of the patient who is currently being

WJPP ter Burg MSc et. al

Health Information Systems

193

Architectures of Hospital
Information Systems
Contextual integration
Condition of an information system in which the context is
preserved when an application component is changed.
The general aim is that a task that has already been
executed once for a certain purpose does not need to be
repeated again to achieve the same purpose. This type of
integration is also referred to as visual integration

WJPP ter Burg MSc et. al

Health Information Systems

194

Architectures of Hospital
Information Systems
For example:
Assume that a nurse first wants to order a lab examination for the patient
Peter Maier using the POE application component, before documenting
certain nursing procedures in her nursing management and
documentation system.
Without context integration, she would have to start the nursing
management and documentation system, login again, and select again
the patient before being able to document the nursing procedures.
Context integration would be achieved when both login (then also called
single-sign-on) and patient selection do not have to be repeated again,
even when changing the application component

WJPP ter Burg MSc et. al

Health Information Systems

195

Architectures of Hospital
Information Systems
Functional integration
Condition of an information system where features needed in
several application components are implemented only once and
can be invoked by other application components
For example,
An EF which should be supported by the patient administration system, the
operation management system, the radiology information system, the laboratory
information system etc.
The hospital information system would be functionally integrated with respect to
coding of diagnoses and procedures if only one application component (e.g., the
patient administration system) provides the features needed for coding diagnoses
and procedures and all other application components can invoke and use them

WJPP ter Burg MSc et. al

Health Information Systems

196

Architectures of Hospital
Information Systems
Process integration
Condition of an information system where business processes are
effectively supported by a set of interacting application
components
For example,
During radiological report writing, the radiologist may need access to
patient data in the clinical information system, the RIS, and the PACS.
These components should interact as transparent and smoothly as possible

Good process integration prevents users from transcriptions and


media cracks
WJPP ter Burg MSc et. al

Health Information Systems

197

Architectures of Hospital
Information Systems
Standards
Regardless the technology for integration used application
components have to communicate if they shall be integrated
A consensus must exist about the syntax and semantics of the
data and messages that are to be exchanged
The most important standards for communication inside hospital
information systems are HL7, DICOM, ISO/IEEE, CCOW and EDIFACT
CDA (Clinical Document Architecture) is a standard for structuring
medical documents and contributes to data integration
WJPP ter Burg MSc et. al

Health Information Systems

198

Architectures of Hospital
Information Systems
Health Level 7 (HL7)
Version 2 is the most implemented communication standard in
hospital information systems for the transfer of messages with data
about the entity types patient and case and the other entity types,
but excluding image data
HL7 describes events and dedicated messages types that are
exchanged between application components
Health Level 7 Version 3 is the newest version of HL7. Unlike version
2, messages in version 3 are derived from a well-defined information
model, the so-called HL7 Reference Information Model (RIM)

WJPP ter Burg MSc et. al

Health Information Systems

199

Architectures of Hospital
Information Systems

Event-driven communication with HL7

WJPP ter Burg MSc et. al

Health Information Systems

200

Architectures of Hospital
Information Systems
Digital Imaging and Communications in Medicine (DICOM)
Digital Imaging and Communications in Medicine (DICOM)50 is a standard
maintained by the International DICOM Committee that addresses the
integration requirements of the medical imaging sector
The standard comprises file and message formats for:

types of medical imaging modalities (e. g., computed tomography, digital x-

ray, magnetic resonance imaging, ultrasound, nuclear medicine


imaging etc.),
a network protocol and
a set of well-defined services

WJPP ter Burg MSc et. al

Health Information Systems

201

Architectures of Hospital
Information Systems
These services, for example, permit:
an imaging modality to retrieve a worklist describing the patients to
be examined from the RIS,
to transmit the images and x-ray dose information created during an
examination to the PACS,
to confirm that the images have been archived successfully (and can
thus be deleted locally) and
to notify the RIS that the imaging procedure has been completed

WJPP ter Burg MSc et. al

Health Information Systems

202

Architectures of Hospital
Information Systems
ISO/IEEE 11073
The ISO/IEEE52 family of standards defines a communication
protocol for the exchange of bio-signals and vital parameters
between various point-of-care devices
Furthermore, the standard enables a dynamic exchange and reconfiguration of devices and remote control, e. g. of infusion
pumps

WJPP ter Burg MSc et. al

Health Information Systems

203

Architectures of Hospital
Information Systems
Standard for Contextual Integration (CCOW)
Contextual integration requires the synchronization of application
components at the workstation
The clinical context object workgroup (CCOW) has developed
standards for the synchronization of application components of
different vendors on one client computer.
It can be expected that CCOW will see increasing acceptance,
especially in (ACn, Vn) architectures

WJPP ter Burg MSc et. al

Health Information Systems

204

Architectures of Hospital
Information Systems
Integrating the Healthcare Enterprise (IHE)
Integrating the Healthcare Enterprise (IHE) is an organization
founded by medical professional societies together with the health
care IT industry with the aim of improving the interoperability of
application components in health care
The approach taken by IHE is to:

analyze typical work processes occurring in health care,


to identify the application components involved in these processes and
the information that should be exchanged between these application
components to support the diagnostic and therapeutic processes as
good as possible
Selecting standards for transactions

WJPP ter Burg MSc et. al

Health Information Systems

205

Architectures of Hospital
Information Systems
Electronic Data Interchange for Administration, Commerce
and Transport (EDIFACT)
EDIFACT5 is a message format developed and maintained by the
United Nations Centre for Trade Facilitation and Electronic Business
(CEFACT)
It is developed as a standard format for electronic data
interchange in electronic commerce (e. g., purchase orders,
dispatch/delivery information, inventory reports etc.)
In health care, EDIFACT is mostly used for communication between
health care institutions in transinstitutional HIS or between health
care institutions and business partners
WJPP ter Burg MSc et. al

Health Information Systems

206

Architectures of Hospital
Information Systems
Clinical Document Architecture (CDA)
CDA is an HL7 document format called the Clinical Document
Architecture and is derived from the HL7 RIM
CDA documents are persistent records of medical information
(such as diagnostic reports, discharge summaries or lab reports),
also based on an XML encoding
Document templates (so-called implementation guidelines)
define CDA based document structures for specific use cases such
as a discharge summary or a radiology report

WJPP ter Burg MSc et. al

Health Information Systems

207

Architectures of Hospital
Information Systems
Integrating technology
To achieve integration within DBn architectures,
integration technologies are used within HIS

several

For closer coupling of application components, we will introduce


federated database systems
For looser coupling, we will look at the possibilities of transaction
management in DBn architectures and then introduce middleware
approaches

WJPP ter Burg MSc et. al

Health Information Systems

208

Architectures of Hospital
Information Systems
Federated database system
A federated database system is an integrated system of
autonomous (component) database systems which are part of
respective application components
The point of integration is to logically bring the database schemata
of the component database systems to a single database schema,
the federated database schema, in order to attain data integration
even when there are redundant data in HIS with a DB n architecture
This virtual federated database schema should be able to be
accessed by application components as though it was a real
database schema
WJPP ter Burg MSc et. al

Health Information Systems

209

Architectures of Hospital
Information Systems
When a federated database system has been implemented for a
given set of application components, software can be developed
that can have read access and, if applicable, write access on the
corresponding data described by the federated database schema.
This method allows for developing new application components
on top of existing ones

The use of the method of federated database systems


should be restricted to situations, when new application
components shall be realized which shall reuse data out of
legacy systems

WJPP ter Burg MSc et. al

Health Information Systems

210

Architectures of Hospital
Information Systems
Transaction Management: 2-phase-commit protocol and master
application components
Transaction management in databases but also in sets of
distributed databases ensures that every update of data, which
are consistent, will lead to another state in which data are
consistent again
Transaction management guarantees consistency of data by
atomicity, isolation and durability of any transaction (ACID
conditions)

WJPP ter Burg MSc et. al

Health Information Systems

211

Architectures of Hospital
Information Systems
The 2-phase commit protocol was developed for transaction
management in DBn architectures
In the initial phase, this protocol checks if the transaction can be
carried out by all affected database systems.
Only if the changes are possible everywhere, they are actually carried
out in in a second phase in all database systems

For carrying out the protocol, the database systems must be


tightly coupled by synchronous communication, and the database
schemata of all involved database systems must be known

WJPP ter Burg MSc et. al

Health Information Systems

212

Architectures of Hospital
Information Systems
Middleware
Generally the term middleware describes the software
components of a computer-based information system that serve
for the communication between application components.
Middleware can be considered as the glue in between
application components, i.e. in the middle of a set of
components
Communication server
Remote function calls
Service-oriented architecture (SOA) and portals

..
WJPP ter Burg MSc et. al

Health Information Systems

213

Architectures of Hospital
Information Systems
Communication Servers
Application component supporting asynchronous communication
between application components. Stands at the center of the logical
tool layer of a hospital information system
Generally speaking, a communication server serves for the
asynchronous sending, receiving, and buffering of messages. It can
also be used to monitor the traffic between application components
The communication server is a tool with which asynchronous
communication can efficiently be supported in order to provide data
integration in a HIS of (DBn, ACn) architecture
..
WJPP ter Burg MSc et. al

Health Information Systems

214

Architectures of Hospital
Information Systems
With the communication server software
message sending can also be done
communication

available today,
as synchronous

For this, the communication server is configured so that the


sending application component is blocked from the time that it
sends a message to the time that it receives a response message
This way, communication servers can be used to provide
functional integration as well

WJPP ter Burg MSc et. al

Health Information Systems

215

Architectures of Hospital
Information Systems
Remote function calls
Middleware components for remote procedure calls (RPC) or
remote function calls (RFC) enable the execution of a procedure
that can run on a remote computer through a process that is
running on a local computer
Synchronous communication is thereby carried out, meaning that
the process in the initiating application component is interrupted
as long as response data from the partner are not obtained

WJPP ter Burg MSc et. al

Health Information Systems

216

Architectures of Hospital
Information Systems
RPC and RFC are classical means for providing functional
integration
They provide a secure and technically well supported way of
synchronous communication between closely coupled application
components.
However, the calling application component is dependent on the
successful response of the called component, and the exchange
of an application component is typically more difficult than using
asynchronous message exchange

WJPP ter Burg MSc et. al

Health Information Systems

217

Architectures of Hospital
Information Systems
Server-oriented architectures (SOA) and portals
A server-oriented architecture is an architectural style of health
information systems where an application component is able to
provide services and/or to invoke services from other application
components (e.g., by remote function calls)

In so-called service-oriented architectures (SOA) an


application component is considered to provide and/or to
invoke services

WJPP ter Burg MSc et. al

Health Information Systems

218

Architectures of Hospital
Information Systems
Some software products to support combination and
orchestration of services are commercially available.
They are usually called integration platforms
Similar to communication servers, they are used both at
construction time to construct integrated application
components and at run time to manage and control
communication and interoperation between connected
application components

WJPP ter Burg MSc et. al

Health Information Systems

219

Architectures of Hospital
Information Systems
Using integration platforms portals can be constructed which do
allow for:
access to certain features i.e. services of the hospitals
application components,
retrieval an computation of data
using the results as input for the invocation of another service
of another application component
SOA is a promising approach for providing not only data
integration and functional integration but presentation integration
and access integration as well

WJPP ter Burg MSc et. al

Health Information Systems

220

Architectures of Hospital
Information Systems
Physical Tool Layer: Physical Data Processing Systems
Application components are logical tools and they cannot exist
without physical tools as a basis. In an information system we can
describe this basis by the physical data processing systems at the
physical tool layer
After this lecture, you should be able to answer the following
questions:
What computer-based and non-computer-based physical data
processing systems can be found in hospitals?
What is meant by the term infrastructure?
WJPP ter Burg MSc et. al

Health Information Systems

221

Architectures of Hospital
Information Systems
Servers and communication networks
Servers are used to provide sophisticated features to clients, can
run databases (database server), and they can run the back-end
part of application software (application server), or support printing
(printer server)
There is a strong trend to virtualize servers. One real server, i.e. a
physical server can simulate lots of so-called virtual servers
This approach makes computing power in a computing center much
more flexible and scalable. It fosters the use of large multipurpose
central computers instead of smaller departmental and dedicated
servers in the past
WJPP ter Burg MSc et. al

Health Information Systems

222

Architectures of Hospital
Information Systems
Virtual servers also result from coupling physical servers in order
to maximize availability by redundancy
Those coupled servers are called a server cluster. It makes sense
to localize the members of the cluster at different sites of the
computing center

Communication networks can be implemented by optical


fibers, copper cables and wireless LAN technologies
Different communication protocols such as Ethernet or
token-ring can be used

WJPP ter Burg MSc et. al

Health Information Systems

223

Architectures of Hospital
Information Systems
Clients
Clients
comprise
all
data
processing
tools
that
are
immediately available to the
various user groups within a
hospital, for example:
a stationary personal computer
a mobile computer, a tablet-pc
mobile devices or a mobile phone a
terminal
a beamer
A health care professional accessing patient information

WJPP ter Burg MSc et. al

Health Information Systems

224

Architectures of Hospital
Information Systems
Storage
Nowadays storage devices regardless of the media used are not
specifically attached to and exclusively used by certain servers.
Moreover so-called storage area networks (SAN) provide storage
services of different kinds to all servers integrated in this network.
This technology allows for scaling up and down quite easily the
storage capacities depending on actual storage needs

WJPP ter Burg MSc et. al

Health Information Systems

225

Architectures of Hospital
Information Systems
Typical non-computer-based
physical data processing
systems
However, in typical institutions, also
a large number of non-computerbased physical data processing
systems are in use.
Typical paper-based physical data processing

A clinical user may, for example,systems


use pencil and paper, telephones,
mobile phones, pagers, typewriters,
fax machines as typical noncomputer-based components
WJPP ter Burg MSc et. al

Health Information Systems

226

Architectures of Hospital
Information Systems
Infrastructure
The set of all physical data processing systems in a health
care institution is called the infrastructure of its HIS
This infrastructure can be described by:
the overall number of physical data processing systems,
or
by the average number of physical data processing
systems per unit
WJPP ter Burg MSc et. al

Health Information Systems

227

Architectures of Hospital
Information Systems
Physical Tool Layer: Integration of Physical Data Processing
Systems
If application components, which shall exchange data and interact
with each other, are installed on different physical data processing
systems at the physical tool layer, these physical data processing
systems have to communicate as well, i.e. integration is needed
After this lecture, you should be able to answer the following
questions:
How can physical data processing systems be grouped and arranged in
order to support application components in an optimal way? What
architectures can result?
What is meant by physical integration?
How do modern computing centers look like?
WJPP ter Burg MSc et. al

Health Information Systems

228

Architectures of Hospital
Information Systems
Taxonomy of Architectures at the Physical Tool Layer
Distribution of Computing Power: Mainframes vs. Client-Server
Mainframe architecture: all computer-based application
components are installed on one or multiple mainframe system(s)
to which various terminals are attached. The terminals cannot
execute applications or store data. We refer to these architectures
as T1
Client server architecture: architectural style at the physical tool
layer, comprising various servers and clients, interconnected by a
network
WJPP ter Burg MSc et. al

Health Information Systems

229

Architectures of Hospital
Information Systems
In a 2-tier architecture:

There is a server that serves both as application and database server


The program execution can partly or completely be given to the client PCs
We will refer to these architectures as T2

In a 3-tier architecture:

There is a separate application server and a separate database server


The database server is responsible for storing the data, on the application
server the application components are installed and executed
We will refer to these architectures as T3

Note: T1 refers to an mainframe architecture

WJPP ter Burg MSc et. al

Health Information Systems

230

Architectures of Hospital
Information Systems
Physical Integration
The types of integration introduced relate to the logical tool layer
and, more precisely, to sets of computer-based application
components.
Physical integration is guaranteed if there exists the physical
communication network for any kind of data exchange
There are six basic physical topologies: bus, ring, linear, star,
tree, and mesh

WJPP ter Burg MSc et. al

Health Information Systems

231

Architectures of Hospital
Information Systems
Bus: Every physical data processing system is directly connected
to the shared transmission medium called bus. There are no
other active devices between the devices and bus
Ring: Every physical data processing system has exactly two
neighbors for communication purposes. Finally the physical data
processing systems are interconnected to form a ring. Data are
passed from one system to the other in the same direction
(either "clockwise" or "counterclockwise") as long as they reach
their destinatio
Linear: Two physical data processing systems are interconnected
in order to form a line. Data are passed from one physical data
processing system to the other as long as they reach their
destination
WJPP ter Burg MSc et. al

Health Information Systems

232

Architectures of Hospital
Information Systems
Star: All physical data processing systems are connected via
two-point connection to a central system which handles data
transmission
Tree: Practically speaking, the tree topology hierarchically
connects two or more star topology networks by connecting
the central physical data processing systems
Mesh (partially connected or fully connected): Each physical
data processing system is connected with one or more
devices; if each device is connected with all other devices on
the network the mesh is called fully connected

WJPP ter Burg MSc et. al

Health Information Systems

233

Architectures of Hospital
Information Systems
Computing centers
Regardless you choose a T1, a T2 or a T3 architecture, the servers
must fulfill special requirements related to availability, stability,
performance, maintainability, and redundancy
When T2 and T3 architectures came up, servers in hospitals were
often installed nearby the departments where the application
components running on these servers had to be used
Last years showed clearly that these solutions are not economical
sound.Hence there is a strong trend back towards centralized
computing centers, this centralization goes well with any of the
T1, T2 or T3 architectures
WJPP ter Burg MSc et. al

Health Information Systems

234

Architectures of Hospital
Information Systems
Summary
The architecture of a hospital information system can be described
using three interconnected layers:
Domain layer
Logical tool layer
Physical tool layer

A major challenge for information management is to integrate the


different application components. Here, integrity as well as
different types of integration need to be achieved. Different
standards such as HL7 or DICOM as well as integration
technologies such as middleware can reduce integration efforts
WJPP ter Burg MSc et. al

Health Information Systems

235

Architectures of Hospital
Information Systems
The architectures of a HIS can be described based on the number
of databases, the number of application components, the number
of software products and the used communication patterns.
The physical data processing systems needed to install the
application components on are described at the physical tool
layer
Availability, stability and performance of the overall computerbased part of the information system significantly depend on a
well organized computing center

WJPP ter Burg MSc et. al

Health Information Systems

236

Vous aimerez peut-être aussi