Health informatics 2

12. Health Information Systems:-

Requirements and Characteristics

Angelika SCHLOTZER 1 , Assoc. Dip. Computing (CIAE), B App. Sc.

(Computing)(CQU), Grad. Dip. Further Education (USQ) a b

, Maria MADSEN BS,

BSc(Hons), GDAC, MB(IS), MACS PhD Candidate b c

a School of Computing, Bundaberg Campus, Queensland

b Central Queensland University, Australia

c School of Management and Information Systems, Director eHealth Education Pty Ltd

Abstract. This chapter gives an educational overview of:

• The purpose of health information systems (HIS).

• The characteristics of health information systems for the future.

• System interoperability as an essential feature in a modern HIS.

• Why user requirements must be established before an HIS is designed.

• How to transform a requirements specification into a request for tender.

Keywords. Information Systems, Health, Systems Analysis, Computer Communication Networks, User Requirements, Software Design, Health Facilities, Systems Theory, Data Management Systems, Database, Computer Security, Request for Tenders (RFT)

Introduction

The purpose of this chapter is to introduce key aspects of information systems design

and development for health care. As such this chapter is not a comprehensive discourse

on information systems development. Health Information Systems (HIS) have some

unique requirements and problematic implementation issues. The implementation and

adoption of electronic health records is both a unique requirement and a problem area.

Another is the need to design or redesign systems to be interoperable with each other.

Yet another, is how to ensure that HIS designed today will survive into the future

through continued change to technology, legal requirements, and policies.

The chapter begins by emphasising the organization as a system and the

importance of the clinical data in the system. Then we discuss database management

systems including distributed systems and systems security. Next interoperability is

examined from a health care perspective. Finally the process of requirements analysis

and specification are discussed since it is more cost effective to get the design correct

than to try to correct the system once it is operational.

1 Corresponding author: [email protected]

Health Informatics E.J.S. Hovenga et al. (Eds.)

IOS Press, 2010 © 2010 The authors and IOS Press. All rights reserved.

doi:10.3233/978-1-60750-476-4-156

156

1. The Systems View of an Organization

The systems view of an organization is the foundation of information systems theory.

An open system accepts inputs from its environment and processes these inputs into

outputs. The outputs and their results feed back into the system so that the system can

continually improve its performance. An open system is also responsive to the

environment in which it exists. In the case of health care organizations, the

environment is a highly political one especially in countries where health care is

publicly funded, Australia for example. Other external influences include standards,

legislation, professional codes of practice, changing technology, and changing medical

knowledge. A system can also be divided into subsystems. Sometimes these

subsystems are logical division or grouping of processes, for example all payroll

processes. Sometimes the subsystems are physically separate systems, for example a

database management system. Thus the scope of an information system project can be

large encompassing a whole of organization, for example an enterprise system, or it

may be small encompassing only one limited subsystem, for example an electronic

order entry system. In this chapter, the scope of the information systems we are

discussing are enterprise wide. Thus a health information system, for our purposes,

encompasses both the administrative information systems and the clinical information

systems in a health care organization.

All information systems, including health information systems, are comprised of

people, technology (eg. computers, networks, databases, input devices, output devices,

and clinical equipment), and the organization (eg. policies, functions, goals,

constraints, and existing resources). These three principle components contribute

equally to the design of a successful information system. The way in which the

technology of the system is connected and integrated constitutes the system’s

architecture. Blobel [1 pp.455- 456

] suggests that “future-proof” health information

systems will need to be designed with the following characteristics:

• distribution;

• component-orientation (flexibility, scalability);

• separation of platform-independent and platform-specific modeling

[i.e.] separation of logical and technological views (portability);

• specification of reference and domain models at meta-level (semantic

interoperability);

• interoperability at service level based on concepts, contexts, and

knowledge (user acceptance);

• enterprise view driven design (user acceptance); multi-tier architecture

(user acceptance, performance, etc.);

• appropriate multi-media GUI (illiteracy);

• common terminology and ontology (semantic interoperability).

A health information system is successful if it does what it is supposed to do and

people are willing and able to use it. What is a health information system supposed to

do? A health information system needs to collect, store, protect, and deliver clinical

data to those who need it for both primary and secondary uses. Modern health

information systems should also implement electronic health records rather than

continuing to rely on paper-based files. Therefore the clinical data is at the heart of the

health information system.

A. Schlotzer and M. Madsen / Health Information Systems: Requirements and Characteristics 157

2. The Value in the System

Clinical data are a valuable and critical resource. All of the other technologies in a

health care organization are there to ensure that clinical data are used appropriately to

deliver safe and cost effective health care. Stead et al. [2] have summarised health care

data as belonging to three overlapping dimensions. The dimensions based on data use

are: Healthcare Provider, Personal Health, and Population Health. In the overlapping

sections of these three sets of data they have grouped the data and information that

must be shared across the sets. At the centre of this diagram are data that must be

shared among all three sets including data for mandatory reporting.

Figure 1 The Three Dimensions of Health Care Data [2

p. 114 ]

Figure 1 highlights how health care data are distributed across many different

organizations, are used for many different purposes, and may exist in many places

simultaneously. Managing the collection, storage, and use of these data is an important

and complex task. There are many groups working on developing methods for

improving the management of health care data. One example is the latest HL7 standard

(version 3) which is based on an object model, the reference information model (RIM).

The rim can be used to guide the development of new health information systems even

A. Schlotzer and M. Madsen / Health Information Systems: Requirements and Characteristics158

though this was not its original purpose. Doing so would simplify the implementation

of HL7 version 3 messaging for those systems. A different method, is the openEHR

archetype approach which takes a higher-level view of health care data. While there

are several different paradigms that can be used for data modeling and management,

see chapter 8, the relational database remains the most widely implemented design and

will be the focus of the discussions that follow.

3. Health Care Data Management

A database management system is a set of computer programs and files designed for

the management (acquisition, organisation, storage, distribution, use, protection,

archiving, and removal) of a data resource. Such a system is customarily purchased as

a package with a number of options from one major software vendor. The features of

these systems are discussed in the next section. The common acronym for database

management system is DBMS. By taking a broad view of the organisation’s

information resources, future uses of information technology can be anticipated and

accommodated without needing to replace or discard the existing investment in

information systems. It has been observed that the data used by an organisation is

relatively stable, whereas the processes that use this data, and the structure of the very

organisation, is not. Separating the design of databases from that of the organisational

units and structures that use the data gives a high degree of independence, stability, and

value. Databases that have been designed with modern, well-developed concepts can

be used to lever the effect of new technology and innovation, and not hold these effects

back.

4. What is it About Database Management Systems That Make Them

Important?

Database management systems are perhaps the primary mechanism for getting control

of the organisation’s information resource. By design, the data within a database can

be shared, it has a logical, meaningful structure, and it can support the strategic and

tactical goals of the organisation. Most, but not all, database management systems will

exhibit all of the following features. A database management system consists of a set

of data (database) stored on files, a data dictionary describing the format, structure, and

location of the data stored, a user interface allowing interactive query and update to the

database, a set of utility programs for monitoring what is happening on the database,

re-organising the database, backing up and recovering the database, and an application

program interface allowing programs written in one of many computer languages to

access the database. Slightly less common features, yet becoming increasingly

important in health information systems, include a system for managing concurrent use

of the system by many people, security and access control features, see Chapter 13, and

higher level languages suitable for developing entire applications. A system is not

complete without the people involved with it. In the case of a database management

system we usually see a database administrator, software developers, and end-users. A

database management system rarely allows access to the data by any means other than

its own software (they are proprietary systems). In many cases this software

implements a security system restricting access to authorised use. By forcing programs

A. Schlotzer and M. Madsen / Health Information Systems: Requirements and Characteristics 159

to use the database management system software, data independence is achieved.

Changes to the database may be made with only minimal changes required to

application programs that use the data.

5. Distributed Databases

Most health care organisations are dispersed, occupying at least several buildings, and

often having offices separated by hundreds of kilometres. The ability to share

information quickly and easily across the organisation is important and essential. Mail

systems, couriers, telephones and facsimile machines are all used to enable this

dissemination. With computer networks, the computer-based information resources of

the organisation can be easily on tap wherever needed. There may be a number of

reasons why a database should be distributed. These reasons are usually based on cost,

performance, or both. Compared with a centralised database, distributed systems offer

the potential for greatly reduced communication charges, since the data resides closer

to where it is actually used. Control of costs can be devolved, and local autonomy and

accountability increased, with distributed databases. Response times for the more

common transactions should improve considerably, since the bottleneck of the central

computer has been removed. Parts of the network may be able to keep operating when

the central site or network is malfunctioning. Some sites may be able to operate at

different hours from others, they may not be constrained by the needs of others.

Growth may be accommodated gradually, without the need for drastic spurts.

6. Health Information System Interoperability

Not only are health information systems within one organization often distributed

geographically, from Fig. 1 above, it is clear that health care data must be shared across

many unrelated information systems and that they will be used for many different

purposes. One of the greatest barriers to the implementation of the electronic health

record is the problem of how to share health care data across these disparate systems.

In this section we present a brief overview of the interoperability as it relates to health

care information.

Morris et al. [3] have investigated interoperability issues in military systems and

have used the diagram in Fig. 2 to illustrate these issues at the different layers of

interoperability from the technical to the political. They suggest that the

Knowledge/Awareness layer is the transition layer where interoperability issues move

from being technical issues to being organizational issues.

Fig. 2 highlights the fact that systems interoperability will not be achieved through

technical solutions alone. Elkin et al. [4 p. 725

] specify three types of interoperability,

pragmatic, semantic, and syntactic that can be applied to the layers of Fig. 2.

1. Syntactic Interoperability - Structural Interoperability

2. Semantic Interoperability - Interoperability of a common and shared

meaning

3. Pragmatic Interoperability - Deals with external constraints on the system.

Here we take to mean how easy is the type of

interoperability to implement.

A. Schlotzer and M. Madsen / Health Information Systems: Requirements and Characteristics160

Figure 2 The Layers of Coalition Interoperability (from Tolk 2003 in [3

p. 9 ]

The lower three layers of Fig. 2 fit under the heading of Syntactic interoperability.

The middle three layers of Fig. 2 fit under the heading of Semantic interoperability.

And the top three layers of Fig. 2 fit under the Pragmatic interoperability heading. It is

the semantic interoperability that has received the greatest attention in recent years in

all information systems including health information systems because semantic

interoperability is thought to be the key to knowledge sharing. Interoperability

between systems using different database designs, different terminologies, and different

infrastructures is difficult but not impossible. The most significant technology to aid

interoperability in the last decade has been the HL7 messaging standards. HL7 has

enabled health information systems that would otherwise be incompatible, to exchange

clinical information with relative ease.

So we now know that a sound database design and semantic interoperability are

two important requirements for future health information systems. But these are broad

categories that tell us little about exactly what it is that is needed by the intended users

of the system. These specific needs are yet to be discovered and will differ in certain

respects from one organization to another even though the general requirements for all

health information systems are the same.

7. Discovering User Requirements

Information systems are built to be used by people to improve productivity, quality,

efficiency, and effectiveness of their work and subsequently improve the outcomes for

the organization. To build a successful information system it is therefore important

that what the users do and what they need is understood. Information systems projects

that follow the guidelines and recommendations of a recognised systems development

methodology, such as performing requirements analysis and specification, and which

have the support of one or more key managers within the organization who will

sponsor the project are the most likely to succeed. It is critical to have such

sponsorship otherwise the project is at risk of being under-resourced, prematurely

terminated, or undermined in other ways.

A. Schlotzer and M. Madsen / Health Information Systems: Requirements and Characteristics 161

There are a number of documents that result from the process of identifying and

specifying requirements. The actual number of documents and the format in which they

are generated depends on the discipline area involved, the guidelines/standards being

used and the anticipated complexity of the new HIS. These standards or guidelines are

not set in concrete. As HIS and other information systems become increasingly more

complex, standards or guidelines are changed to adapt to these new levels of

complexity 2 . The “Open Group Architecture Framework” [5] provides a

comprehensive and detailed approach to systems development that is focused on

requirements management. For our purposes, only the major pieces of documentation

generated from a requirements analysis will be discussed based on information systems

and information technology discipline guidelines.

7.1 Requirements Analysis

Once the decision has been made that an HIS is needed, the first step is to determine

and document the requirements of the new system. Any errors or omissions made at

this stage become very costly if they have to be fixed at a later stage. For example,

Boehm and Basili [6] have identified that problems can be 100% more expensive to fix

once a system has been implemented than if they had been found and corrected during

the requirements or design stages. So it is well worthwhile to invest the time and

resources needed to fully identify requirements.

Sharp, Rogers, and Preece [7 p.474

] argue that there are two main aims in

undertaking requirements activities. One aim is to understand as much as possible

about the users, their work and the context of their work, so that the system can support

them in achieving their goals; this we call “identifying needs”. Building on this, our

second aim is produce, from the needs identified, a set of stable requirements that form

a sound basis to move forward into thinking about design.

This is also a good time to review workflow practices to determine whether any

changes are needed. The resultant requirements will also form the basis on which

“request for tender” documents are generated. More discussion on this follows later.

The sole focus of a requirements analysis is what the new system needs to do to

fulfill the goals and needs of its stakeholders, not on how this will be accomplished.

There are, however, constraints that do need to be considered; for example – the

amount of funding available; reporting requirements; the organization’s strategic

objectives; and legislative requirements.

7.2 Stakeholders and Identifying Needs

It should by now be clear that all stakeholders must be involved in order to fully

identify requirements. This includes everyone from top-level administrators to

clinicians and technical staff. In some cases, it may also include external entities, for

example, researchers. Each group of stakeholders has differing expectations, work

functions and needs that the HIS is expected to address. For example, top-level

administrators are generally interested in various reports that enable them to make

management decisions. These are usually summaries that contain aggregated data such

2 An example of this complexity can be found at the web site for The Open Group [http://www.opengroup.org/] which is an international consortium who envisage a global Boundaryless Information Flow™.

A. Schlotzer and M. Madsen / Health Information Systems: Requirements and Characteristics162

as how many patients presented with a communicable disease in the past quarter or

statutory reports required by government. At the other end of the spectrum are the

people at the “coalface”, those clinicians who need to enter information applicable to

an individual patient or update inventory and so on. These are significantly different

perspectives of the system. Earlier systems were largely developed to meet top-level

administrator needs, but dealt poorly (if at all) with the needs of other users. A

stakeholder group that feels their needs are not being met by a system will circumvent

it or possibly even undermine it.

There are a number of techniques that can be used to establish stakeholder needs.

The major ones are interviews, focus groups, analysis of existing documents, observing

users at work, questionnaires, use cases to visually illustrate a workflow practice and

scenarios used to narrate workflow practices. Once this data has been collected, it is

collated into the Needs Document (ND). This document is then analysed to group

needs into categories and to identify overlapping needs. The output of this process is

the Needs Analysis Document (NAD), which is reviewed with representatives of

stakeholder groups for confirmation of accuracy. The NAD is written more concisely

than the ND. Needs are stated in terms that can lead to verifiability in the completed

system, but still in a natural language that non-technical users can understand. In

addition, the needs are prioritised in case budget constraints lead to a situation where

all of the needs cannot be implemented at this time. These needs become the user

requirements in the formal Software Requirements Document.

7.3 Software Requirements Document

The Software Requirements Document (SRD) (also referred to as System or Software

Requirements Specification (SRS)) consists of two major parts [8 p. 98

]:

• User requirements: statements (including diagrams) in natural language of the

services the system is expected to provide and any constraints under which it

must operate.

• System requirements: a detailed set of precise, unambiguous statements about

system services and constraints. These may be used as a contract between the

system purchaser and the system developer.

Box 1 provides an example of User and System requirements specifications.

Requirements tend to be classified as functional or non-functional. Functional

requirements correspond to the user requirements; i.e. the services that the system

should provide. Non-functional requirements are constraints under which the system

will operate. Examples of a few of these include system response times, backup

requirements, documentation standards, interoperability requirements (e.g. how this

system will “communicate” with one or more legacy systems), privacy and

confidentiality requirements, which user groups have access to which information and

so on. How many and what type of non-functional requirements need to be included

depends on the HIS to be developed. An example of a non-functional requirement

might be: After five continuous minutes of keyboard inactivity, the system should

blank the screen and lock the computer.

A. Schlotzer and M. Madsen / Health Information Systems: Requirements and Characteristics 163

Box 1 Example User Requirement and System Requirements Specification

The software requirements document can be used as a basis for either the purchase

of off-the-shelf systems software and hardware or for producing requests for tender for

purpose built systems. The next section explains what is in a typical request for tender.

8. Requests for Tender

As stated earlier, requirements form the basis on which request for tender (RFT)

documents are prepared. Whether these requirements should be the user requirements

or the system requirements specifications tends to be an area of debate. There are a

number of factors that will influence the decision including the uniqueness of the

system to be developed, whether system development will be outsourced or in-house,

whether an off-the-shelf system is to be purchased, the criticality of system

requirements and so on. For example, assume that the intention is to purchase existing

software from a vendor. There could be a number of vendors who offer software that

might satisfy the new system’s requirements. If you talked with each of these vendors

about your system needs, each one would praise their product as being the best

solution; however, each product will have somewhat different functionality. To ensure

that all vendors need to address all of the requirements of the new HIS without stifling

potential innovative vendor solutions or adaptations, the user requirements would be

included in the RFT. The content and format of RFT documents tend to vary, but the

Pharmacy Guild of Australia’s RFT document content sections provide a good

example. These are outlined in Box 2. As you can see, the RFT document in this

example is very detailed and can be adapted to suit most RFT needs.

Health information systems are complex systems and present the developer with

some unique problems and requirements. Most important of these requirements are the

management of clinical data for both primary and secondary uses. Blobel [1] identifies

portability, flexibility, user acceptance, semantic interoperability, performance, and

scalability as some of the key features required for “future-proof” health information

systems. Performance and user acceptance are features that are unlikely to be met

unless a full Requirements Specification is produced before a new system is purchased

or a Request for Tender is released.

An example of a documented user requirement: 1. The system must provide users with the ability to access and deal with basic client information in a

timely manner.

A few of the corresponding set of System Requirements Specifications might be:

• Users should be able to add a new client record to the system interactively. This information consists of the client’s name, address, contact details, date of birth, gender, marital status, next of kin, Medicare number and private health care provider (if any) details.

• Users should be able to update an existing client’s record details interactively.

• Authorised users should be able to delete an existing client record.

• The system must respond to requests to add, update or delete a client record within a maximum of

10 seconds.

A. Schlotzer and M. Madsen / Health Information Systems: Requirements and Characteristics164

Conclusion

This chapter has described the characteristics of and why we need to adopt the use of

information systems in the health industry. The need for system interoperability

between health information systems was explained. Indeed it was demonstrated that

system interoperability is an essential feature of successful Health Information System

implementations. This is largely dependent upon having identified well developed user

requirements to ensure that the systems adopted are designed to meet user needs. The

chapter concluded with the presentation of how user requirements specifications can be

transformed into requests for tender.

Box 2 Outline of Sections in a Request for Tender Summary

LODGEMENT OF TENDERS

For hand delivery

For postal delivery

COPIES REQUIRED

FAX TENDERS

LATE TENDERS

CONTACT OFFICER

PART A – CONDITIONS OF TENDER

1. Invitation

2. Enquiries by tenderers

3. Lodgement of tenders

4. Alterations, erasures, additional information or illegibility

5. Ownership of tender documents

6. Tender validity period

7. Compliance

8. Language, measurement and currency

9. Tenderers to meet costs

10. Tenderers to inform themselves

11. Improper assistance and collusive tendering

12. Affirmative action

13. Acceptance of tenders

PART B – STATEMENT OF REQUIREMENT

1. Background

2. Research Requirements

3. Management of the Project

4. Reporting Requirement and Deliverables

5. Costing the Evaluation

6. Contracting the Evaluation

PART C – EVALUATION PROCESS AND RESPONSE FORMAT

1. Evaluation Method

2. Tender Evaluation Criteria and Information Required from Tenderers

3. Compliance Criteria

4. Evaluation Criteria

5. Achieving the Requirement

6. Tenderer's Capacity and Infrastructure

PART D – DRAFT CONDITIONS OF CONTRACT

A. Schlotzer and M. Madsen / Health Information Systems: Requirements and Characteristics 165

References

[1] Blobel, Bernd. 2007. Comparing approaches for advanced e-health security infrastructures. International Journal of Medical Informatics 76, no. 5-6: 454-459. http://www.sciencedirect.com.ezproxy.cqu.edu.au/science/article/B6T7S-4M7CMJS- 1/2/9a636c5588b29f43261d1215ab74c4a6.

[2] Stead, WW, BJ Kelly, and RM Kolodner. 2005. Achievable Steps Toward Building a National Health Information Infrastructure in the United States. Journal of the American Medical Informatics Association 12, no. 2: 113-120.

[3] Morris, E, L Levine, C Meyers, and D Plakosh. 2004. System of Systems Interoperability (SOSI): Final Report. SEI Technical Report. Pittsburgh: Software Engineering Institute.

[4] Elkin, Peter L, David Froehling, Brent A Bauer, et al. 2007. Aequus Communis Sententia: Defining Levels of Interoperability. In Medinfo 2007, ed. Klaus A. Kuhn, James R. Warren, and Tze-Yun Leong, Part 1:725-729. Brisbane: IOS Press.

[5] The Open Group. 2008. The Open Group Architecture Framework Version 8.1.1. Organization. The Open Group - Making Standards Work. http://www.opengroup.org/architecture/togaf8- doc/arch/toc.html.

[6] Boehm, B, and VR Basili. 2001. Software Defect Reduction Top 10 List. IEEE Computer 34, no. 1: 135-137.

[7] Sharp, H, Y Rogers, and J Preece. 2007. Interaction Design: Beyond human-computer interaction. 2nd ed. Milton.

[8] Sommerville, I. 2001. Software Engineering. 6th ed. Essex: Pearson Education Limited.

Review Questions

1. Explain why the clinical data is the most valuable asset in a health information

system.

2. Examine the Request for Tender document outline, above, and briefly describe

what might be found in the compliance section of an RFT for a new order entry

system in your country.

3. Discuss performance improvements when clinical data are distributed across

different areas (geographical or functional) of the organization for: a) a system that

still uses paper-based records; and b) a system that has implemented a complete

electronic health record.

4. Examine the features of a “future-proof” health information system as suggested

by Blobel et al. (2007). Why is user acceptance found in this list? And who do

you think are the users to whom the authors are referring?

5. Explain why requirements specifications are about “what” is required in the

system and not “how” the system should be built?

A. Schlotzer and M. Madsen / Health Information Systems: Requirements and Characteristics166

Copyright of Studies in Health Technology & Informatics is the property of IOS Press and its content may not

be copied or emailed to multiple sites or posted to a listserv without the copyright holder's express written

permission. However, users may print, download, or email articles for individual use.