Integration of medical, safety, industrial, hygiene,
environmental, training, chemical, and other
information improves occupational safety and employee
morale.
The Problem Organizations collect a considerable
amount of information
on employee health and safety -- much of it required
by law. They also
collect environmental and chemical information
relating to employees.
Even in this age of technology, much of this kind of
information ends up
on paper stored in filing cabinets. Sometimes, an
organization will use
a computer program (a database) to store some of this
information, but
often, the organization's various systems can't
communicate with one
another. As a result, users must enter data multiple
times into several
systems. What's more, the divided nature of such
systems makes it
difficult, if not impossible, to "mine" for trends
among the
information.
The Software Solution DataPipe takes a different
approach from
traditional systems. The software provides a uniform
system into which
users can enter many kinds of information. DataPipe
users can enter
information from other computer systems, through voice
dictation (speech
to text), by interfacing to test instruments and from
external documents
(reports, graphs, photos, maps, etc.) stored as images
and other
standard computer formats.
A DataPipe system is made up of a series of "modules,"
each addressing a
particular kind of information. DataPipe's modular
format lets customers
tailor their systems to the information they want to
maintain; they
don't pay for modules they don't need. And all
DataPipe modules can
communicate with each other. As a result, the addition
of new modules to
the system makes all existing information available to
new modules, and
vice versa. DataPipe uses conventional personal
computers, networks and
the Microsoft Windows( environment now widely familiar
and used.
While other systems might require users to learn
different systems for
each kind of medical and other information, DataPipe
provides a uniform
"look and feel" to its operation. Once a user learns
the system for one
module, he or she knows how to use all of the modules.
The screen colors
and symbols, controls and menus, sub-systems for
writing reports or
looking up information, etc. work in the same way in
all modules.
Compatibility In addition to providing a uniform
method for entering and
recalling information, DataPipe also provides
alternate methods for
putting data into the system. Users can connect test
instruments
directly to computers running DataPipe. Users can send
test data from
instruments directly into corresponding modules. As a
result, DataPipe
users don't have to manually read out data and type it
into the
database. Similarly, DataPipe has built-in support for
directly reading
other common computer data files, so users can update
the DataPipe
system with information from other systems (e.g. a
corporate personnel
system). DataPipe can also send information to other
systems. Clinic
services, for example, can be forwarded to an
accounting system.
A common, time-consuming and expensive task in
medicine is the
dictation, transcribing and editing of notes on clinic
visits. Several
DataPipe modules have been designed to link with the
leading medical
voice dictation system, so a physician can "click" on
a Dictate "button"
on the DataPipe forms, dictate a Progress or SOAP Note
and automatically
enter the resulting text into the DataPipe database.
Other sources of information for DataPipe are reports,
instrument
graphs, lab results, images and photographs, maps and
more, which can be
in the form of images produced by scanners, files from
word processing
systems, spreadsheets, etc. These other kinds of
information can be
linked to DataPipe, allowing users to locate and
review information from
a single, uniform DataPipe system.
Security Whenever a variety of users can access
various types of
information in one computer system, security is a
concern. Not everyone
has the same "need to know" access to all the data on
the system.
DataPipe has a built-in security system that controls
who can see
certain types of information and performs certain
types of tasks. Each
user can access only his or her individual version of
DataPipe upon
logging into the system. If a user doesn't have
permission to access a
particular module and its information, he or she
cannot access it; that
module isn't part of the user's system.
Easy-to-Use People who use DataPipe are typically not
computer experts.
They are doctors, nurses, managers, supervisors, lab
technicians,
engineers and factory workers. Organizations around
the world dealing
with many different kinds of information use the
program. The Windows
environment, combined with the common operations
designed into DataPipe,
have consistently shown the system to be easy to learn
and use on a
day-to-day basis. It lets people store, and even more
importantly,
locate various types of information in a simple, but
integrated manner.
The ability to store medical, safety, industrial
hygiene, environmental,
training, chemical and other information in a single,
integrated system
has many benefits. DataPipe users can not only recall
information in a
simple, standard way, but also develop reports to
examine
cause-and-effect relationships between the workplace
environment and
medical and safety conditions. A major international
corporation, for
example, was able to produce monthly health and safety
reports to senior
management - in just two minutes - using DataPipe.
Previously, it took
personnel two weeks to produce these reports each
month. OSHA is
rewarding a small, but growing bakery, which used
DataPipe to analyze
its occupational injury and illness data, with a
special category for
organizations who have maintained particularly good
control over their
workplaces.
DataPipe has helped its users in both expected and
unexpected ways. It
has provided users with an integrated, multi-user,
expandable means for
entering, storing, recalling and analyzing many
different kinds of
medical, safety and other information encountered in
the workplace.
DataPipe allows users to transfer data directly from
instruments to the
database, dictate notes that are automatically entered
into the
database, develop and store reports, store images,
documents and more.
Organizations have been able to decrease time and
costs for collecting
and analyzing their medical, safety and related
information, sometimes
from weeks to minutes.
What has surprised DataPipe system users is the
unexpected ability to
find "hidden information" in their data. DataPipe
allows users to
integrate information into one system, providing a
method for exploring
relationships that previously didn't appear to exist
or could only be
accomplished by periodically copying data out of
multiple systems into
spreadsheet or statistical software for periodic
analysis.
With DataPipe, looking for cause-and-effect between
workplace exposures
to chemicals and resulting medical problems becomes
considerably easier.
Likewise, analyzing injury and illness information
collected in one
DataPipe module with respect to types and causes of
incidents, body part
affected, etc. has allowed organizations to identify
problem areas that
will benefit in the most number of reduced accidents
and injuries. One
DataPipe user is currently applying to OSHA for
recognition under the
U.S. Department of Labor's "Voluntary Protection
Program" for
improvements in their health and safety record
resulting from analysis
made possible through DataPipe. Currently, only 244
companies in the
entire country have achieved this special designation.
Today, a reduction in money allocated for health,
safety and other
support programs is limiting their availability. A
DataPipe system not
only shows organizations where they can best focus
their attention to
benefit the most people, it also improves the ability
to find small
problems before they become big issues. Users are
implementing DataPipe
modules to define job requirements in terms of
training, personal
protective equipment and physical capabilities of
individuals (strength,
range of motion, etc.). They are also using the
software to match these
characteristics with the skills, capabilities, etc. of
employees to
identify suitable jobs and to identify temporary jobs
employees can
perform while recovering from an illness in lieu of
medical leave.
Finally, by relating job performance metrics with
injury and illness
data, users can apply DataPipe to identify areas that
show improvements
or to determine the benefits of improving training,
physical
conditioning programs, and more, in an effort to
decrease employee
injuries. All of these uses lead to a safer, healthier
work environment.
The single largest contribution information technology
has made to the
development of DataPipe is the widespread acceptance
of personal
computers and computer networks. We had determined
that the complexity,
costs and centralized philosophy of mainframe and
large minicomputer
systems didn't lend themselves to systems like
DataPipe. Mainframe and
large minicomputer systems simply don't put computing
power into the
hands of the direct providers and information users.
PCs and networks
brought about a great change.
Before the PC We began working with the predecessors
of PCs in the late
'70's, connecting them to health and safety
instruments and storing test
information in small database programs. Time after
time, we heard from
corporate users who fed information into a mainframe
computer and,
received at best, monthly printed reports. Meanwhile,
small desktop
computers were performing tasks with instruments, data
and interactive
data retrieval and reporting which users felt should
also be feasible
with the mainframes. One corporate medical director
told us, "All I do
is send in my data once a month. I never get anything
back." His
mainframe-based recordkeeping system was inadequate
from his viewpoint.
In the early '80's, we developed a UNIX-based
occupational health and
safety system, which used IBM AT-class machines
running SCO UNIX and
character mode terminals. UNIX, however, was not as
accepted as it is
now; users wanted their PCs and, in some instances,
the networks they
were connected to, as well.
Thus, it was the evolution of PCs and networks into
the powerful,
reliable systems they are today that provided the
computing environment
users wanted.
Windows The development of Microsoft Windows and
associated tools and
databases also helped form DataPipe. The now-familiar
"graphical user
interface" most of us take for granted was a new
concept for PCs in the
mid-to-late '80's. We found that new users immediately
took to the idea,
often forcing the introduction of Windows into their
organization solely
on the basis of using DataPipe. Once again, users got
what they wanted.
Although we had an existing system in the form of the
UNIX-based
application, DataPipe's development began with a
totally clean slate. We
took what we had learned, along with what users did
and didn't like, and
added requirements for new functionality. These new
design requirements
included module independence, common operations and
support tools (e.g.
report writers), as well as the ability to handle
images and external
documents, and to interface instruments.
The spread of small computer systems and
microprocessor technology also
impacted the design of test instruments. In the early
'70's, it was rare
to have an instrument that could store and transfer
data to a computer.
A common technique at the time involved connecting an
analog-to-digital
converter component to the strip chart recorder on an
instrument to
"steal" the signal in real-time. The technique
required a minicomputer
like a PDP-8 - hardly a portable system. We were
working with these
systems, automating analytical laboratories.
A New Computer Port In the late '70's and early '80's,
instruments began
appearing with RS-232 or other semi-standard computer
ports. We worked
with several instrument manufacturers to design, build
and program these
systems. In some instances, the manufacturer also had
software
available.
It is now very common for medical and many other
instruments to store
data, or at least to come with a basic computer
interface for capturing
test data as it is produced. We no longer have to
design and build
custom hardware for this purpose. The incredible
decrease in component
costs for ROM and RAM memory and UARTS for the RS-232
interface, have
brought the component costs for adding a computer
interface to an
instrument to under $100.
Incompatibility Between Manufacturers One thing that
hasn't changed, and
probably won't for a considerable time to come, is the
many and varied
ways in which each instrument vendor formats the test
data and controls
the instrument via the computer. Between manufacturers
of even the same
basic type of instrument, there is complete
incompatibility. One system
might store multiple tests and send them to the
computer on command.
Another system may simply send its data out the
computer interface port,
assuming something is there to get the data. Another
system may format
the data in fixed field formats, while yet another
sends a duplicate of
the data as it appears on a built-in printer. Other
differences include
ASCII versus binary data, a presence or absence of CRC
check sums and
hardware or software (e.g. ENQ/ACK) handshakes for the
data transfer.
Some vendors don't have written documentation defining
what their
instrument sends. In one instance, we found that the
brother-in-law of
the company president had written the instrument's
software. There was
no documentation. Some medical instrument vendors try
to prevent the
users from accessing the data by claiming their format
is "proprietary."
That's why we encourage organizations purchasing any
kind of instrument
with a computer interface, medical or otherwise, to
make the release of
the instrument's data format and control instructions
part of the
purchase requirements.
DataPipe Communicates Solving these instrument
interface issues was
another part of the DataPipe design requirements. We
developed a
"driver" methodology described below to successfully
allow DataPipe to
communicate with any and all instruments, as long as
they have either a
common computer interface (e.g. RS-232), or produce a
data file which
can be read by Windows programming tools (e.g. DOS
file structure). We
have included additional write-ups on this methodology
in our Time
Capsule.
While others have built systems that implement parts
of what DataPipe
does, no one, to our knowledge, has a system that
covers the range of
data types, instrument interfacing, image and document
support, speech,
etc.
Several vendors of medical instrument have software
that reads data from
proprietary instruments, and stores the data in a
computer. These
programs, however, work with just their own makes and
models.
Several years ago, one vendor developed a system that
worked with
different basic types of instruments. The "catch,"
however, was that all
the instruments had to come from that vendor. If a
medical group wanted
to use a different model, they couldn't.
DataPipe can work with instruments from multiple
vendors simultaneously.
It is also possible to find programs that store and
organize certain
kinds of specialized data. There are individual
programs for medical,
safety and environmental, but only DataPipe provides
an environment that
lets an organization combine the many different kinds
of occupational
health, safety and environmental data in a single
system with a common
method of operation. Only DataPipe allows any and all
information to be
used and compared with any other information in the
system.
Similarly, there are stand-alone systems for storing
and managing
documents and images. DataPipe takes this a step
further by integrating
this function into the rest of the system, so it
becomes another tool
for the user to take advantage of as the need arises.
DataPipe was developed because of various requests
from many kinds of
customers. We worked with instrument manufacturer
customers to develop
software for their systems. They wanted a single
computer program that
would work with any instrument. Until DataPipe, each
instrument needed
its own proprietary program and database.
Our customers using a system developed under UNIX for
text-based
terminals, wanted a system that they could assemble by
choosing from a
wide variety of components, or modules, to give each a
system specific
to their needs without having to buy pieces they
didn't want.
Finally, when the development of DataPipe began in the
mid '80's, PCs
and PC networks were becoming more powerful and
reliable. Customers
wanted a system that would work on the computer
systems they had
directly available. They did not want another
mainframe system with its
associated costs and lack of accessibility.
A final element in the design criteria was to use
Microsoft Windows,
which was new at that time. Few users had even seen
Windows back then,
but we felt the environment just might come to
something, and chose to
use it in the development of DataPipe.
With the understanding that DataPipe continues to
evolve because of
changing user and regulatory requirements, it is an
operational program
in use at hundreds of sites around the world by
thousands of users. All
of the original design goals have been met. More
importantly, as
customers find interesting problems and create
requests, the design
continues to grow to meet their needs. New modules,
additions or changes
to existing modules, improved data reporting and
analysis tools. We
release other improvements from time to time. We even
provide tools for
installing changes to the databases, so the customer
doesn't have to
re-load data after making a change to the database.
We've developed a
set of tools that allow organizations with multiple
locations around the
world (the current record-holder is 54 sites) to
easily exchange local
data with corporate headquarters using a combination
of their
(world)wide area network and e-mail.
Future plans fall into three categories: First, we
will continue to
develop new modules to meet the needs of our customers
and to respond to
new government recordkeeping and reporting
requirements. Second, we will
continue to make changes to the internal workings of
DataPipe to improve
performance. Right now, we are working on a series of
improvements for
security, searching for data, and additional functions
in the ad-hoc
report writing system.
Finally, we have a long-range project underway for
rewriting DataPipe to
take much more advantage of distributed objects,
client/server
technology and more complete database independence.
DataPipe has been a
technology leader, and we intend to keep it that way.
DataPipe performs several tasks, each of which is
difficult in itself.
When combined together into a single system, the level
of difficulty
increases. We have many things that are internally
difficult, but seem
easy to the user of the system.
Major areas of difficulty have included:
Instrument Interfacing. We provide a software program
called a driver
for each instrument make and model. The driver knows
how to communicate
with its instrument, and puts the data into a standard
format for the
basic family to which the instrument belongs. A
standardized input
routine then brings in and validates the data from all
instruments in a
single family. We can support a new instrument simply
by writing a new
driver, a process similar to how a printer
manufacturer provides
software to allow Windows to recognize a new printer.
Module Independence. A DataPipe module is a collection
of databases,
computer screens (forms) and reports associated with a
particular kind
of information. For example, some typical medical
modules include:
Clinic Visits, Medication, Immunizations &
Inoculations, Progress Notes,
Scheduling, Vision, Spirometry, Audiometrics and
Hematology.
Each module is essentially a stand-alone component
that allows a
customer to pick and choose which module to use or not
to use, while
still maintaining the ability to add new modules
later. By developing
and maintaining internal standards for the database
tables and
communications between modules, we have created a
system that meets all
these goals, while allowing us to develop completely
new modules that
work with existing ones.
Image and Document Integration. Databases typically
store text, numbers,
dates, times and similar conventional information.
DataPipe's design
requires the ability to include various types of
images and external
documents from other common programs, such as word
processors and
spreadsheets.
DataPipe treats images as external files (in
approximately 40 different
formats). While it is not uncommon for specialty
applications to use a
proprietary image file format, it was, and is, our
belief that this
restricts users. We've seen too many instances where
an application
program is no longer supported, leaving organizations
unable to use them
with other software. We decided to support the common
image formats
(TIFF, PCX, BMP, etc.). For performance reasons,
however, we developed
the DataPipe Image Viewer, a sub-system that comes
with DataPipe that is
optimized for viewing, printing, zooming and otherwise
inspecting image
files. For security reasons, the Image Viewer does not
allow users to
edit images. Users cannot, for example, alter an image
of an EKG strip
with the Viewer. The Image Viewer supports color,
gray-scale and black
and white (document) images. Viewing an image in
DataPipe is as simple
as clicking on the field on the screen form; DataPipe
automatically
takes care of passing the file to the Image Viewer,
and does the rest of
the work for the user.
While users could convert other computer-based
documents to images and
store them in that format, we wanted a method for
connecting the
DataPipe database to the actual documents. As a
result, we implemented
Windows Object Linking and Embedding (OLE) in
DataPipe. This allows, for
example, someone to always view the most recent
version of a protocol,
policy, etc. from the DataPipe database. As the
original documents are
updated with a word processor, the OLE link with
DataPipe maintains the
current version in the database.
Network Independence. Computer network operating
systems can become near
religions within an organization. Some standardize on
Novell Netware.
Others use Windows NT, Banyan VINES, various versions
of UNIX, DEC's
Pathworks and more. Within some organizations, there
are mixes of
networks. The protocols used on the various networks
also vary; IPX,
NetBEUI, TCP/IP and so on. The bevy of choices makes
the developer's
decision difficult.
The network and/or protocol an organization uses
doesn't affect
DataPipe. If Windows runs in the chosen environment,
and user
workstations can see the servers from their copies of
Windows' File
Manager, DataPipe should run on the system.
Security. Multi-user applications in general need a
mechanism to control
who perform which tasks within the system. Systems
containing medical
and other sensitive information have even more
restrictions, both
ethically and legally. DataPipe has its own security
system, which is
subservient to the network's security as a first level
of defense.
Within DataPipe security, users can be completely
blocked from not only
accessing individual forms and their associated data,
but also from even
knowing that those forms are in the system. When each
user logs into
DataPipe each time, the security sub-system assembles
the allowed
modules and forms for the user, and then builds an
associated menu
structure for this version of the system. Even if a
user tries to run a
report that contains information from a module the
user doesn't have at
least "read" address to, the security sub-system
prevents the report from
running.
User Training and Documentation. The majority of
DataPipe documentation
is in the form of four on-line manuals. They range
from the general User
Guide (which yields about 600 pages if printed in its
entirety) to the
very specific manuals for DataPipe System
Administrators, Help on Help
(how to use the standardized on-line manuals for
searching, customizing,
etc.) and Form Specific Help.
All documentation uses a standard interface. Each
document has been
totally cross-indexed, and can be searched for any and
all words and
phrases individually or in combinations using
conventional logic. Users
are permitted to print the manuals, in whole or in
part, and may add a
customized "footer" to the bottom of each printed page
if desired. The
on-line documentation can also be annotated with color
highlights,
"post-it" notes and bookmarks to allow local
customization of the
documents.
By design, the operation of DataPipe is standardized.
This means that
new users can become functional in the system with a
few hours of
training. For the most part, once a user has learned
how to add new
data, recall and edit existing data and run reports,
he or she can use
the same techniques on each and every module,
regardless of the kind of
information. With more than 100 forms available in
DataPipe, this
"common look and feel" becomes extremely important to
using the system.
It also means that an organization can add new modules
to their system
and immediately begin using them; they work the same
way all the others
do. There has not been a single instance where a
customer has added a
new module and has needed additional training from us.
Ease of Use While conducting DataPipe training for the
Medical
Department of an electric utility located along the
East Coast, a
secretary said, "I don't want you to take this the
wrong way, but once
you understand the basic concepts, this system is
really simple." She
was concerned we would think we were wasting her time
going through the
entire system, practice exercises, etc., during a
two-day training
session. She was surprised when we said, "That's the
nicest thing you
could possibly say." We constantly hear from our
customers that DataPipe
is easy to use. It was designed to be that way! The
DataPipe computers
and software are doing the hard work of collecting and
integrating the
different kinds of data, freeing people to do what
they're best at doing
- thinking about problem solving.
Whether they're MDs or nurses creating ad-hoc reports
to look for
relationships between workplace exposures and medical
problems, or
factory workers looking up on-line Material Safety
Data Sheets for the
effects of chemicals they work with, DataPipe users
become familiar with
and functional in the system with a few hours of
training. We typically
provide a two-day course to introduce DataPipe to an
organization, to
cover the common form concepts, developing reports,
and more. Often,
organizations then use our training materials
(computer-based
presentations) to hold their own in-house training
session.
Included on a disk in the Time Capsule is a DataPipe
training
presentation prepared with Microsoft PowerPoint.
Another pair of disks
contains a Harvard Graphics (player included) slide
show demonstration
of DataPipe.
Knorr
Associates 
