Chapter 2
Information Systems Theory
and Life Cycle
1
© 2007
General Systems Theory
• A system is a set of elements that work together to
achieve a common goal
• A formal systems methodology ensures a more valid
and reliable information system
• At a minimum, an information system has:
–
–
–
–
–
–
Boundaries
Inputs
Processes
Outputs
Goal directedness
Goals
© 2007
Examples of Systems
• Mechanical systems – developed by humans but can
operate without human intervention
– Air conditioning systems (process) heat and cool (output) the
air (input) to make humans comfortable (goal)
• Human systems – organized relationships among people
– Healthcare system brings together healthcare workers (input)
to treat (process) patients (input) so their disease (input) is
cured (output/goal)
• Man–machine systems – operations that assist humans
in the performance of their work
– Filing system identifies the sequence in which paperwork
(input) is to be arranged (process) for ease (goal) of later
retrieval (output)
© 2007
General Systems Theory
• Systems can be characterized as being either
deterministic or probabilistic
– Deterministic system
• Parts function according to a predictable relationship
• Example: When an alarm clock is set, it will chime at the
time specified
– Probabilistic system
• All relationships among the parts cannot be defined in
advance
• Example: Humans will eat, sleep, grow, and age, but no
one can determine precisely how tall one will be or when
one will die
© 2007
General Systems Theory
• Systems may also be classified as being closed or
open
– Closed
• All parts operate
without external influences
together
– Open
• Parts of the system
are impacted by or
interact with the environment
© 2007
Interoperability
• Interoperability is the ability to exchange data among
information systems
– “Because EHRs are essentially a system of systems, they
depend on being able to connect with many systems”
• EHRs, therefore, should be open systems where they
conform to open, or readily available, standards
• However, “open systems” has come to mean that anyone
may have access to the underlying software and
frequently for free (“freeware”)
© 2007
Information Theory
Information
Source
Destination
Example:
Observation
about a patient
Channel
Example:
Sign of
disease
Transmitter
Receiver
Example:
Medical
record
Example:
Example:
Documentation,
or report
Clinician, or
monitoring device
© 2007
Information Theory
• Data Flow
– Basic information theory describes the flow of data from an
information source to its ultimate destination.
• Data Sources
– Input requires an information source.
– In the case of health information, the source is generally an
observation about a patient or a response to a question
asked of the patient.
• Data Uses
– Information theory recognizes not only the flow of data,
but also how data are used, how they may be converted to
information, and how experience may be applied to the
information to support the creation of knowledge.
© 2007
Data-Information-Knowledge Continuum
KNOWLEDGE
Experience added to
information
This patient has an
infection. I will
order an antibiotic
Patient: Mary Smith
INFORMATION
Data that have been
organized &
processed
DATA
Basic facts and
observations
This is higher
than yesterday
Temperature is
101.2 F
Vital Signs
© 2007
Data Quality
• For data to contribute to meaningful information, it
must be:
–
–
–
–
–
–
–
–
–
–
Accurate
Complete
Timely
Precise
Current
Granular
Relevant
Defined
Accessible
Consistent
• For data to be processed into information
computer, it must be structured data
by a
© 2007
Information Systems
• Use devices to capture data in multiple formats that are
converted to a machine-processable state
• Apply instructions (also converted into a machineprocessable state) to index, store, calculate, compare,
and perform other functions on the data
• Use devices to display the original data at another time
or place
• Use devices to present the results of calculations,
comparisons, and other functions to users in various
formats
© 2007
Role of Technology in Healthcare
• No matter how well an EHR is designed, it is still just a
tool
• It can be designed to “learn” and “predict,” but it is
incapable of heuristic thought, or having “gut instincts”
• Personal vigilance in the form of professional judgment
must be applied to
use the tool
properly
(Reason)
© 2007
Characteristics of Information Systems
• Hardware and software provide the
equipment and computing instructions,
but . . .
• People – are the key reason for
information systems to exist, but they
often are the most difficult element of the
system to manage
• Policy – refers to directives or principles
upon which people perform their work;
policies are needed to ensure information
systems success
• Process – the manner in which a task is
performed. Process change is one of the
most significant factors in success or
failure of EHRs
© 2007
People, Policy, and Process
• Relationships between component parts (objects) and
their properties (attributes)
– Disparate parts must work together to process information and
with all people who are stakeholders for a successful EHR
• Unity of purpose causes the parts to have integrity
– Policies set the boundaries for adoption and realization of
EHR benefits
• Feedback mechanisms provide information about
environmental factors that interact with the successful
functioning of the system
© 2007
Cybernetics
• Theory of control in which systems accept input,
process it, and produce output relative to sensors
that monitor against standards and hence control
processing and inputs to ensure the best possible
results
© 2007
Systems Development Life Cycle
• Purpose of systems and information systems
theory is to appreciate the steps necessary to
develop, or at least plan for implementing an
EHR
• Two perspectives:
– Traditional SDLC from developer’s (e.g., vendor or
self-developer) view
– SDLC for project management where a system is
acquired
© 2007
Traditional SDLC Methodology
Six steps:
1. Feasibility
2. Analysis
3. Design
4. Implement
5. Test
6. Maintain
© 2007
SDLC Step 1: Feasibility
• The existing (manual) system is evaluated and
deficiencies are identified
• The result is the determination as to whether it
makes sense to proceed with the project
© 2007
SDLC Step 2: Analysis
• New (automated) system requirements are
defined
• Deficiencies in the existing system are addressed
with specific proposals for improvement
© 2007
SDLC Step 3: Design
• The proposed system is designed
• Plans are laid out concerning:
–
–
–
–
–
–
Physical construction
Hardware
Operating systems
Programming
Communications
Security issues
© 2007
SDLC Step 4: Implement
• The new system is developed
• The new components and programs are obtained
and installed
• Users of the system are trained in its use, and all
aspects of performance are tested
• If necessary, adjustments are made at this stage
© 2007
SDLC Step 5: Test
• The system is put into use
• The new system can be phased in, according to
application or location, and the old system
gradually replaced
• It may be more cost-effective to shut down the
old system and implement the new system all at
once
© 2007
SDLC Step 6: Maintain
• When the new system is up and running for a
while, it should be exhaustively evaluated
• Maintenance must be kept up rigorously at all
times
• Users of the system and support documentation
should be kept up to date concerning the latest
modifications and procedures
© 2007
SDLC for EHR Project Management
Pharmacy System
Initiation
CPOE
Spiral
Model
EMAR
Initiation
Initiation
Planning
Planning
Acquisition
Planning
Acquisition
Implementation
Acquisition
Implementation
Implementation
Operations
Disposition
Operations
Disposition
Operations
Disposition
© 2007
Initiation
• Addresses feasibility (cost) and analysis
(benefits)
– Sets goals and defines expected benefits
– Anticipates organizational changes
– Identifies budgeting, scheduling, staffing,
communications
– Initiates change management
© 2007
Planning
• Provides overview and engages all
stakeholders
– Delineates staff roles and responsibilities
– Process mapping to specify functional
requirements
– Identifies technical requirements
– Plans project and risk management methodologies,
including deliverables, controls, conversion, bridge
technologies
– Staff development
– Documentation
© 2007
Acquisition
•
•
•
•
•
•
Market research to understand what is available
Request for proposal
Due diligence for vendor of choice
Contract negotiation
Approval to acquire product
Financing
© 2007
Implementation
• Install, customize, and turn over to users for adoption
–
–
–
–
–
–
–
–
–
–
–
Issues management
Change control
Turnover strategy
Plan and carry out training
Plan and carry out testing
Install hardware and software, including communications
and network components
Implement security controls
System build (including data modeling, table and file
creation, template building, report development)
Data conversion
Go-live
Acceptance
© 2007
Operations
• Ongoing support to keep system current and
accurate
–
–
–
–
–
Performance measurement
Benefits realization
Maintenance
Upgrades and patches
User preference changes
© 2007
Disposition
• Orderly transition from vendor to organization
• May also include
– Equipment obsolescence
– Upgrading hardware and software
– Ceasing to use, or rely as heavily upon, bridge, or
interim, components
• Example: Amount of bulk scanning may decrease
considerable as more data are entered directly by users
• Example: A standalone e-prescribing system adopted
prior to EHR will no longer be used
when full
EHR incorporates e-prescribing
© 2007
Conclusion
• EHR is a system of systems, each having inputs,
processes, outputs, boundaries, and goals to
which the integration of systems is directed
• A systematic approach to developing or
acquiring an EHR is essential to ensure that all
elements, including hardware, software, people,
policies, and processes are in place and working
successfully together to achieve the best possible
results
© 2007