You are on page 1of 7

The e-Baby Data Warehouse: A Case Study

Carolyn McGregor
Centre for Advanced
Systems Engineering
University of Western
Sydney
c.mcgregor@uws.edu.au
George Bryan
Centre for Advanced
Systems Engineering
University of Western
Sydney
g.bryan@uws.edu.au
Joanne Curry
Centre for Advanced
Systems Engineering
University of Western
Sydney
jm.curry@uws.edu.au
Mark Tracy
NICU
Nepean
Hospital
Sydney
Australia


Abstract

Neonatal Intensive Care Units (NICUs) require
equipment and facilities to assist and monitor premature
and some term babies. This equipment outputs
physiological and clinical data, but current research does
not provide doctors with techniques for capturing this
data in a format suitable for analysis and research.
Additionally, regional hospitals provide limited NICU
support, but without access to a Neonatologist, the baby
must be moved to another hospital. This paper details the
framework for clinical and physiological data capture,
the storage structures within the e-Baby Data Warehouse
and information access through a secure Intranet/Internet
browser. The key contribution of this work is the
infrastructure that provides a platform for patient
information data capture, storage, display and analysis. A
key benefit of this work is to provide a mechanism for
Neonatologists to receive information directly from a
regional hospital, thereby preventing, in some cases, the
immediate need to move the baby.

1 Introduction

The Nepean e-Baby Project is a non-profit consortium
between neonatal medical specialists at the Nepean
Hospital and the Centre for Advanced Systems
Engineering (CASE), University of Western Sydney
(UWS). This consortium was set up three years ago to:

investigate innovative ways to address the problems
of handling large volumes of patient data;
improve communications and data capture between
disparate databases and complex medical machinery
via electronic linking;
integrate and display data in a way that would
facilitate the ability of clinicians to recognise new
disease patterns.

In this paper we describe the architecture developed to
collect, store and display high frequency stream data
supplied by multiple disparate devices to facilitate further
analysis of the captured data. Data collection is via the
use of 'data sockets' that enable the extraction of data
from disparate databases and complex medical
machinery. Data storage is through the use of a Data
Warehouse. The User Interface is accessible via a secure
Intranet/Internet browser.
This paper further describes the application of that
architecture to a specific case study known as e-Baby.
The e-Baby case study provides an architecture to collect,
store and display information from within the Neonatal
Intensive Care Unit at Nepean Hospital, Penrith Australia.
We begin with a brief overview of the architecture. We
then introduce the case study and describe its specific
goals and objectives. This is followed by a description of
the Data Collection, Data Warehouse, Model Base and
User Interface components as they relate to the case
study. The prototype section details the prototype that has
been developed to validate the application of this
architecture to the Neonatal Intensive Care Units case
study. Other research that relates to this work and future
research opportunities are then described.

2 Architecture

The need to collect, store and display information has
been the subject of much previous research [1, 2, 3, 4] and
led to the development of the research area known as
Decision Support Systems. Decision Support Systems
(DSS) is a term first used by Gorry and Scott Morton in
1971 [1]. Keen and Scott Morton [2] detailed the
following three objectives for a DSS:

1. Assist managers in making decisions to solve semi-
structured problems
2. Support the manager's judgment rather than trying to
replace it.
Proceedings of the 35th Hawaii International Conference on System Sciences - 2002
0-7695-1435-9/02 $17.00 (c) 2002 IEEE 1
3. Improve the manager's decision-making
effectiveness rather than its efficiency.

Sprague and Watson [3] and Turban [4] identify that a
DSS is composed of the following architectural
requirements:

Data Management - including the databases
containing the relevant data and the software to
manage the data

Model Management - qualitative models that
provide the system's analytical capabilities

User Interface - through which the user
communicates with and controls the DSS

Through the use of the previously defined DSS
principles, the major components of this architecture have
been defined as follows:

Data Collection - represents the systems and
equipment from which data will be collected.
Data Warehouse - serves as the data repository. It
holds snapshots of organisational data together with
high frequency stream data.
Model Base - stores the associated organisational
models that serve as the basis for research and
decision support.
User Interface - provides access to the clinical and
physiological data through a secure intranet/internet
browser.

Each component of this architecture is discussed
further in the following section, and then defined in the
context of the case study.

3 Case study

In this section, we present a case study in which the
architecture is applied to a specific form of intensive care
unit used for premature babies as well as some born at
term, known as a Neonatal Intensive Care Unit (NICU).
Our goal is to demonstrate the concepts discussed so far
using a concrete example.

3.1 Introduction
The business case contained in this case study relates
to a Neonatal Intensive Care Unit (NICU) located at
Nepean Hospital, Penrith, Australia. Nepean hospital is
one of eight tertiary referral centres for the care of
critically ill pre-term newborns, handling 700 babies
annually. Several electronic instruments monitor a babys
vital signs such as blood oxygen, blood pressure and heart
rate. A major limitation in clinical management is that
these monitors are not linked to provide an integrated
picture of the babys condition.
Approximately eighteen per cent (18%) of babies born
in New South Wales require special care or neonatal
intensive care admission [7]. Premature babies can be up
to 17 weeks early and may only weigh 450gms; they can
spend 3 or 4 months in intensive care and have dozens of
specific diseases before discharge. Ten percent of
severely ill babies will die and 15% of survivors will have
significant life long disability. Premature babies, by the
time they are discharged, can increase in body mass by as
much as six times, and have had dozens of medical
diagnoses and treatments. Many of these may have long
term implications for the future health of the individual.
Typical medical records for the most premature babies
consist of manually prepared paper notes that detail
enormous data collection and can weigh up to 3- 4
kilograms. The preparation of these notes is dependent on
the hand-annotated records of nursing staff, usually at 60
minute intervals, and 30 minute intervals at best. It is very
common for critically ill babies to have significantly
abnormal variation in the measured parameters minute by
minute that are not recorded in the notes. Frequent
transient falls in blood pressure and blood oxygen
content, often with swings into the high range, may be of
critical importance in survival and quality of survival free
of significant disability [6]. Also, the collection of the
information contained within the baby's notes to form a
discharge letter represents a manually intensive analysis
of physiological statistics, together with the replication of
clinical data that can take the Neonatologist many hours
to produce.
The hospital maintains manual, and limited electronic
records of patient clinical and physiological data. They
have a range of monitors and other equipment that may be
attached to each baby and/or their crib at any given point
in time, however, the information collected by these
monitors is not available in electronic form for future
reference, analysis or research purposes.
As a result, the NICU requires a means to utilise the
information collected by these monitors to improve its
knowledge of each baby's condition and to enable future
medical research.
In addition, fifteen percent of neonatal intensive care
admissions are transferred after delivery from smaller
hospitals without intensive care facilities. Similar
conditions apply within Australia, New Zealand and the
USA where small non-tertiary units are spread throughout
the country. Transferred critically ill, term and pre-term
babies have higher mortality rates and much higher rates
of long term disability than similar babies born in
hospitals with intensive care facilities.
Hence the NICU would like the ability to obtain
information from the monitors attached to babies that are
not physically located at that specific hospital, but
perhaps at another regional hospital where only limited
Proceedings of the 35th Hawaii International Conference on System Sciences - 2002
0-7695-1435-9/02 $17.00 (c) 2002 IEEE 2
support for premature babies exists. Regional hospitals
have equipment to provide limited NICU support, but
without the ability for a Neonatologist to receive
information from this equipment, the baby must be moved
to another hospital with Neonatologist support. Given the
critical requirement to maintain a consistent environment,
moving a baby at this time can be life threatening.
Similarly, a Neonatologist need not be located at a PC
within the hospital to view patient data, but should be free
to view this information through any secure
Internet/Intranet connection.
Finally, the hospital would like the ability to generate a
discharge letter incorporating the ability for the system to
perform the physiological summaries required together
with the extraction of the necessary clinical information.
We begin with the goals and objectives of the NICU as
they relate to this case study. This is followed by a
description of the architecture and the data collection,
data warehouse, model base and user interface
components as they relate to this case study known as the
'e-Baby Data Warehouse'.
3.2 Goals and objectives

The following objectives have been identified to assist
the NICU in improving its support for premature and ill,
term babies:

Automated Reporting providing continuous stream
snapshot readings from all the attached monitors and
equipment
Remote Viewing of the monitors and equipment
attached to a crib and/or baby
Central Repository for Data Collection
Access to Historical Data for research and analysis
purposes
Seamless Movement of Patient Records
Reduction in the need to move the patient from
regional hospitals
Infrastructure to support Localised Clinical Trial
Analysis
Ability to generate a Discharge Letter
3.3 Architecture

To address the objectives defined for the NICU, the
architecture previously defined is now applied to the case
study for the NICU at Nepean Hospital.
Data received from the patient records system via the
clinical database is loaded into the Data Warehouse base
tables. Summary tables within the Data Warehouse are
then populated using the information supplied.
Additionally, devices such as ventilators and blood
saturation monitors producing high frequency data
streams provide a stream of data through to the Data
Warehouse. Doctors utilise the information contained in
the tables of the Data Warehouse to perform analysis and
research. Extracts of data from the Data Warehouse are
used to populate clinical research data marts. A discharge
letter module produces a discharge letter on screen, that
may also be printed. This concept is illustrated in Figure
1.

Ventilator
User Interface
Clinical
Database
I
N
T
E
G
R
A
T
I
O
N
DATA WAREHOUSE
T
R
A
N
S
F
O
R
M
A
T
I
O
N
Clinical
Research
Data Mart
Data
Socket
Blood Saturation
Monitor
Data
Socket
Discharge
Letter

Figure 1 e-Baby Data Warehouse Architecture
Each component of this architecture is discussed
further in the following sections.
3.4 Data collection

There are two primary categories of information that
are collected through the Data Collection process. The
first is the static classification data that is supplied via
periodic extracts of snapshots of the clinical databases.
The second is the high frequency data streams that are
produced via the monitoring devices and other equipment.
Each medical instrument has its own unique
communication protocol. A mechanism was required to
extract information from a range of medical instruments
and format this information in a standard format high
frequency data stream.
The concept of a 'Data Socket' (also referred to as a
'Data Integrator') was introduced to enable this
information to be captured and forwarded through to the
data warehouse. These data sockets represent software
that extracts the information from the specific device in
electronic form, through its communication output port.
The data socket attaches a device ID denoting what
device it is attached to and a reference ID denoting which
baby it is attached to, it then formats the data received
into a standard format that can be transmitted as part of a
high frequency data stream. The data elements contained
in the high frequency data stream supplied by each data
socket may be as follows:

Device ID
Proceedings of the 35th Hawaii International Conference on System Sciences - 2002
0-7695-1435-9/02 $17.00 (c) 2002 IEEE 3
Indicator ID
Reference ID
Date/Time Stamp
Predefined goal setting
Reading

Within this case study, the high frequency stream data
is represented by the patient's physiological data. Clinical
data is also collected via the hospital's transaction
processing systems. The following sections further
describe both categories of data.
3.4.1 Physiological data

Ill and premature babies are monitored intensively with
several devices measuring physiological parameters such
as blood pressure, blood oxygen, heart rate and carbon
dioxide levels. These data are measured and displayed by
the millisecond and the attending nurse writes down a
spot value every 30 or 60 minutes. Dramatic and
significant changes can occur minute by minute and
important events and trends are lost by the lack of
electronic capture.
Lister et al [7] details the following sample of monitors
and other equipment from which physiological data may
be captured.

Ventilators for set & delivered Peak Inspiratory
Pressure, set & delivered mean airway Pressure, set
& delivered Positive expiratory Pressure, Inspiratory
time, rate, mode of ventilation eg trigger or high
frequency ventilation (HFV), amplitude (HFV only),
Hertz (HFV only), Fi0
2
fractional inspired oxygen
concentration, tidal and minute volumes, derived
parameters of dynamic compliance and resistance,
and-pressure/volume and pressure/flow loops
Hewlett Packard monitors for heart rate,
transcutaneous oxygen saturation, invasive blood
pressure, respiratory rate, and significant pauses in
breathing (apnoeas) and temperature
Dedicated pulse oxymetry monitors for
transcutaneous oxygen saturation, heart rate and
transcutaneous oxygen saturation
Dedicated pulmonary mechanics monitor
(Ventrak) for delivered Peak Inspiratory Pressure,
delivered mean airway Pressure, delivered Positive
expiratory Pressure, Inspiratory time, rate, tidal and
minute volumes, derived parameters of dynamic
compliance and resistance, pressure/volume and
pressure/flow loops
Arterial blood gas & Lactate measurements from
blood gas machine integrate with clinical database

Figure 2 details the NICU physiological data
collection. At any given point in time, a range of monitors
and other equipment may be attached to each baby and/or
their crib. These monitors and other equipment are
attached to a 'data integrator' or 'data socket' that captures
the data in electronic form and forwards it through to the
local data warehouse located on the 'Local Data
Collection Unit'. Within the architecture as shown in
Figure 2, monitors and other devices are attached to a
multipurpose Data Integrator that services more than one
device. This architecture may also be implemented via
implementation of multiple data sockets attached to
individual devices. A touch screen, may also be attached
to each crib that will allow staff to enter standard readings
eg. A false alarm, for a given device alert. At periodic
intervals, the Local Data Collection Unit will forward
data through to the Data Warehouse located on a High
Performance Data Server. Access to information
contained within the warehouse is available via an
application accessible through a secure internet/intranet
browser.

Fiber optic backbone Localdata collection
NIC Unit
Nepean Hospital
Station 1 Station 2
Crib Crib
Ventilator Ventilator
Blood
Saturation
M onitor
Blood
Saturation
M onitor
Data
Integrator
Data
Integrator
HP
Com ponent
M onitor
HP
Com ponent
M onitor
Visualisation
PC
Touch screen Touch screen
Printer

Figure 2 NICU Architecture Infrastructure
The elements of data contained in the high frequency
data stream are now described as they relate to this case
study.
The device ID, provides a mechanism to identify the
monitor or other device that is attached to the baby and/or
crib. Indicator ID provides the ability to uniquely identify
multiple reading types produced by the same device. For
example, dedicated pulse oxymetry monitors provide
information relating to heart rate and transcutaneous
oxygen saturation. The reference ID enables the reference
of a device to the baby to whom it is attached. A date/time
stamp registers when the reading occurred. The
predefined goal setting is required for devices where an
optimum setting or goal state can be recorded, as in the
case of a ventilator where a goal for Peak Inspiratory
Pressure is set and then the delivery of ventilation is
measured through the use of the reading field.
3.4.2 Clinical data

Additional static information is collected for the
patient through the capture of clinical data such as sex,
gestational age, antenatal steroid use and degree of
perinatal asphyxia. This data is extracted from the
hospital's existing transaction processing systems.
Proceedings of the 35th Hawaii International Conference on System Sciences - 2002
0-7695-1435-9/02 $17.00 (c) 2002 IEEE 4
3.5 Data warehouse

In recognition of the need to store information used for
decision making in a separate structure, away from
transaction processing data storage, the concept of data
warehousing was introduced. The Data Warehouse term
is usually based on relational database management
systems, (RDBMS) [9] and represents the relational
database technology's method of supporting decision
making.
Inmon [5] defined that a Data Warehouse is a
database created specifically for the purpose of business
analysis, in contrast to On-Line Transaction Processing
(OLTP) systems, established for automating business
operations. Inmon further went on to define a Data
Warehouse as a subject oriented, integrated, time variant,
non-volatile, collection of data in support of management
decisions [10].
The data warehouse within this architecture receives
and stores information from the clinical databases
together with data streams received from monitoring
devices and other equipment. The data warehouse
supplies information to users by supplying data to the user
interface components as well as to specialised data marts.
The physiological data received from the high
frequency data streams is transferred to a physiological
base table contained within the Data Warehouse that has a
table structure that matches the format of the data
received. The clinical data, received from the hospital's
clinical databases is used to construct a profile for each
baby.
The high frequency stream data is accrued at the rate
of approximately 10 MB/Baby /Day. Historical replicas of
the clinical data are not currently part of this architecture.
As such any updates to the clinical data contained for a
given baby are used to replace current values within the
warehouse. The storage requirements for the clinical data
are therefore only in the order of 300-500K/Baby.
Through the use of the Data Warehouse architecture
two primary forms of data summarisation occur to
provide support to analysis and research initiatives.
Firstly, various clinical measures are stored as part of the
profile for each baby and may be used to enable
summaries of clinical statistics, for example, the baby's
gestation at birth is used to group and classify babies for
further analysis. Secondly, these same measures may also
be used to group and classify physiological data and to
enable the creation of summary tables.
3.6 Model base

The Model Base provides the architecture with the
environment for the storage and management of the
population of organisational models. The design and
structure of these models is dependent on the goals of
each individual implementation.
Brookes [13], Alter [12] and Turban [4] have
determined a diverse range of ways to classify models and
to use these classifications as tools to assist the
organisation in determining models to be developed.
Bayesian Reasoning is a general statistical approach
invented several hundred years ago by the Revered
Thomas Bayes. It obtains an estimate of the posterior
probability P(H) of an hypothesis H by combining the
probabilities of one or more pieces of evidence e(i).
Lister et al [6] have designed Bayesian models for the
Clinical Risk Index for Babies (CRIB) and the Score for
Neonatal Acute Physiology (SNAP), both of which were
scoring methods developed by Richardson et al [14].
These models will utilize the physiological data collected.
The development of other modules depends on the
further requirements of the hospital and the
Neonatologists. These modules would provide the ability
for the clinical measures to drive summarisation and
analysis as described in the previous section.
Neonatal research has developed to the point where the
presence of certain physiological measurements or
indicators can predict future physiological episodes. The
development of models incorporating these known rules,
will enable alert based reporting to enable pre-emptive
treatments to be administered.
In addition, a discharge letter module constructs a
discharge letter that can be displayed on screen or printed.
Printing of this is still required within the medical
community to form part of the standard medical paper
archives. This module performs the physiological
summaries required together with the extraction of the
necessary clinical information. There is also the ability for
the Neonatologist to add additional comments.
3.6.1 User Interface

The user interface provides the ability for remote
replication of VDUs from equipment and monitors as well
as enhanced viewing of summarised data for analysis
purposes through the use of a secure Internet/Intranet
browser.
The comparison of extracted result data to predefined
benchmarks allows concise situational analysis. This
analysis provides the hospital's management and
analysts/researchers with the information to support their
individual organisation function.
3.7 Hospital infrastructure
The hospital infrastructure is illustrated in Figure 3.
Individual NICU units located at different hospitals will
each have their own local data collection facility that will
act as a local storage replicator. At periodic intervals,
these local data collection units will forward data through
Proceedings of the 35th Hawaii International Conference on System Sciences - 2002
0-7695-1435-9/02 $17.00 (c) 2002 IEEE 5
to the high performance data server. A suitably
configured stand alone Data Integrator, connected to a
monitor located at a regional hospital or transport unit,
will be capable of downloading data directly through to
the High Performance Data Server. This will provide the
ability to monitor patients in remote locations ie prior to
transfer to an intensive care facility.

Local data collectio
NIC Unit
Nepean Hospital
Local data collection
NIC Unit
King George V Hospital
Data Integrators
Data Integrators
Internet
High Performance
Data Server
UWS, Penrith
A stand alone
Data Integrator

Figure 3 e-Baby Hospital Infrastructure

4 Evolution of the Architecture

While all the goals for the project were considered in
the development of the architecture over time, there were
three initial predominant drivers to the first stage of
development on the e-baby architecture, namely:

Access to Historical Data for research and analysis
purposes
Infrastructure to support Localised Clinical Trial
Analysis
Ability to generate a Discharge Letter

The availability of historical data to support clinical
trial analysis was of particular interest to the
neonatologists to assist in the analysis of a new piece of
medical equipment that was under development and trial
within the NICU at Nepean Hospital.
Due to the volumes of information collected during the
extended stays of the babies within the NICU, the
completion of discharge paperwork for one baby would
represent several hours of collation, analysis and
documentation. The introduction of automation in this
process would represent significant productivity gains for
both the neonatologists and nursing staff.
The initial architecture designs represented the clinical
and physiological data collection, storage and display in
separate, autonomous systems. It was realised however,
that for all the objectives to be met, this data would be
required to be co-located and integrated to enable
maximum research and process support functionality.
The introduction of the high performance data server,
and the integration of the databases on the local collection
units provided the framework to establish the complete
integrated architecture as shown in Figure 3.

5 Prototype

The previously described case study has been
implemented via a prototype. Data Sockets have been
developed and attached to both Dragar Ventilators and HP
Merlon monitors, located at the NICU at Penrith Hospital,
to enable the capture of high frequency stream
physiological data. These Data Sockets forward the data
through to an SQL Server Database acting as the Local
Data Collection Unit. Conceptual design work has
commenced to update the data sockets to output the high
frequency data stream in an XML format.
Clinical data is currently received and stored in an
Access 2000 database. Work has commenced on porting
this functionality across to the SQL Server acting as the
Local Collection Unit.
A discharge letter is being generated that extracts the
necessary clinical information. It also summaries
physiological data from the devices where data sockets
have provided the information as well as the summaries
of the readings taken by the nurses from the remaining
monitors and devices that were attached at some point
during the baby's time in the NICU. There is also the
ability for the Neonatologist to add additional comments.
Preliminary discussions have been held with a regional
hospital that has been targeted to participate in the
prototype. Discussions have also been held with the New
South Wales Department of Health to enable the
implementation of this architecture at other hospitals with
NICUs.
Discussions have also commenced with committee
members of the Australian Centre for Advanced
Computing and Communications (ac3) [11] to establish a
High Performance Computing node at Penrith and to
utilise this for the High Performance Data Server.

6 Related work

Inmon [5] has provided a generic framework for the
development of Data Warehouses. This research further
develops the Data Warehouse concept to cater for high
frequency stream data such as that contained within the
monitors and equipment used within an NICU.
Previous work completed by Lister et al [6] introduced
the concepts of the e-baby architecture but focused on the
use of Baysian analysis techniques to assist with research
on the information stored within an unspecified Data
Warehouse structure. This research developed a generic
overall architecture together with the data collection, data
storage and user interface requirements. This research
Proceedings of the 35th Hawaii International Conference on System Sciences - 2002
0-7695-1435-9/02 $17.00 (c) 2002 IEEE 6
also applies this architecture to the specific e-baby
implementation.
The Australian Centre for Advanced Computing and
Communications (ac3) is a High Performance Computing
Centre. It was established as a result of a partnership
between the NSW Government, Australian Technology
Park (ATP), the University of Sydney, the University of
Technology, Sydney, Technical and Further Education
(TAFE) and industry partners including IBM, NEC and
SGI [11].
As part of the ac3 strategy, high performance
computing nodes are being established throughout NSW.
CASE, UWS has a key role in enabling the establishment
of the Penrith Super Computer Node Beowulf Cluster,
which will be located at the Penrith campus of UWS. One
of the objectives of ac3 is to facilitate the transmission of
medical images from regional areas. Discussions have
commenced with ac3 regarding the establishment of the
Penrith Super Computer node and it is envisaged that this
will be used for the High Performance Data Server.

7 Future work

The work described in this paper can be extended in
several ways for future research. Firstly the architecture
can be further applied to other case studies to further
validate the framework. Other such case studies could
include an adult intensive care unit.
Secondly, this architecture could be applied to data
received from any medical practitioner thus providing the
ability to construct a life long centralised patient medical
record.
Thirdly, this research could be extended to develop
further models beyond the Bayesian Analysis models
detailed in [6].
Finally, this architecture could be applied to other
scenarios where high frequency stream data is supplied,
for example racing car performance information where
onboard telemetry reads information on every aspect of
the cars performance.

8 Conclusion

This paper has presented an architecture to collect,
store and display high frequency stream data supplied by
multiple disparate devices to facilitate further analysis of
the captured data. Data collection is via the use of 'data
sockets' that enable the extraction of data from disparate
databases and complex medical machinery. Data storage
is through the use of a Data Warehouse. The User
Interface is accessible via a secure Intranet/Internet
browser.
The presented case study and associated prototype
provided a mechanism to validate the application of this
architecture to Neonatal Intensive Care Units.

9 References

[1] Gorry G.A., Morton M.S.S, A Framework for
Management Information Systems, Sloan Management
Review 13, Fall 1971, pp55-70.

[2] Keen, P., Scott Morton, M,S., Decision Support Systems:
An Organizational Perspective. Addison-Wesley, Inc.,
Reading, MA, 1978.

[3] Sprague R.H. Jr, Watson H.J., Decision Support Systems -
Putting Theory into Practice 2
nd
Edition, Prentice Hall,
Eaglewood Cliffs, NJ, 1980.

[4] Turban, E., Decision Support and Expert Systems:
Management Support Systems, 4
th
Edition, Macmillan
Publishing Company, NY, 1995 .

[5] Inmon, W.H., The Data Warehouse All the Data at Your
Fingertips, Communications Week, August 29, 1994.

[6] Lister, R., Bryan, G. and Tracy, M., The e-Babies Project:
Integrated Data Monitoring and Decision Making in Neo-
natal Intensive Care, Proceedings of the European
Conference of Information Systems (ECIS2000), 2000.

[7] 1994 NSW Midwives Data Collection

[8] Alberman E, Botting B., Trends in prevalence and
survival of very low birth weight infants, England and
Wales: 1983-7, Archives of Disease in Childhood 1991;
66: 1304-1308, 1991.

[9] Strange, K, Data Warehousing: Rehashing Decision
Support, Oracle Magazine, January,/February 1995 pp9 -
10, 1995.

[10] Inmon, W.H., Building the Data Warehouse, Second
Edition, John Wiley & Sons, NY, 1996.

[11] www.ac3.com.au accessed May 31
st
, 2001.

[12] Alter S.L., How Effective Managers Use Information
Systems, Harvard Business Review 54, Nov-Dec, 1976,
pp97-104.

[13] Brookes, C.H.P., A Framework for DSS Development,
Information Systems Forum Report, 84/1, 1984.

[14] Richardson DK, Gray JE, McCormack, et al. Score for
neonatal acute physiology severity index for neonatal
intensive care. Pediatrics 1993; 91: 617-23

[15] Bryan, G., Curry, J., McGregor, C., Holdsworth, D.,
Sharpley, R., Using XML to Facilitate Information
Management Across Multiple Local Government
Agencies, Proceedings of the 35
rd
Hawaii International
Conference on System Sciences (HICSS-35), Big Island
Hawaii, Hawaii, 2002.


Proceedings of the 35th Hawaii International Conference on System Sciences - 2002
0-7695-1435-9/02 $17.00 (c) 2002 IEEE 7