DataPipe USA Inc. - Providing EHS Software Solutions Since 1979 (40 Years!)

Contact DataPipe USA DataPipe EHS Software Sales

EHS Software, Environment and Waste Management, Occupational Health and Medical, Industrial Hygiene and Safety

Welcome    DataPipe Overview    Our Approach    DataPipe In Depth    FAQs    Online Demo    Customer Support    Contact Us

Awards and Certifications

DataPipe USA
Butler, NJ

Year: 1996
Status: Laureate
Category: Medicine
Nominating Company: Kurzweil Applied Intelligence

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

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
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

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
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,

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

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

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

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.



DataPipe Overview

History of DataPipe USA

News and Events

Awards and Certifications

Helpful Websites

Employment Opportunities


Article and Newsletters


Learn about the next few steps.

Please call our sales department for a 10 min phone consultation.



Register for an Online EHS Software DEMO

Access our system and see DataPipe live as we move through various forms and reports.


EHS Software Module Descriptions

Copyright DataPipe USA Inc. 1979 - 2019.         Privacy Policy         SiteMap (XML, HTML)

DataPipe USA is a service-disabled veteran-owned small business