From Knorr Associates - Providing EH&S Software Solutions Since 1979

Welcome to DataPipe USA      The DataPipe Approach      DataPipe In Depth      FAQs      Online Demo      Customer Support      Contact Us

New Page 1

Occupational Health & Safety magazine

October 2000

Get More from Your OHS Software System

Whatever approach or combination of approaches you take, each has advantages and disadvantages.

by Peter Singer   October 2000

OHS software systems--or any Enterprise Resource Planningclass (ERP) system for that matter--can allow you to view information in different ways. Often, such a system may provide a set of pre-built reports that can be used out of the box. These pre-built reports are generally useful only up to a certain point. Whether a company must adhere to government, organizational, site, or a boss's requirements, there is always someone who wants to see the information a different way.

There are several options available to OHS software vendors regarding which report-writing mechanisms to offer their clients, such as providing a set of pre-defined reports, including a report writer available within the software, and allowing the user to develop his or her own reports with an external reporting tool. Whatever approach or combination of approaches you take, each has advantages and disadvantages.

Reporting Options Within the System

Some OHS software packages have a mechanism for generating reports from within the system, whether ad hoc or something more advanced. More often than not, clients need to be able to modify such reports or to create their own reports.

If the system comes with its own report writer(s), someone needs to learn how to use it, and must understand the OHS software's underlying data structure. Although an ad hoc-type report writer might offer an easy point-and-click interface and function with little or no training on the user's part, it may be limited when more exotic reports need to be generated.

A more advanced report writer may offer its own programming language and reporting environment.

 Ideally, it might use a reporting language that would involve little or no learning by a person tasked with writing a report. Visual Basic for Applications (VBA) is one such example. For those familiar with Microsoft Office, the term may sound familiar. VBA ( is a Microsoft®-developed technology incorporated into the Office suite of applications, as well as many other applications. If you've ever written a macro in a recent version of Word or Excel, you've used VBA.

Other software vendors may incorporate VBA into their applications. There's an advantage to using VBA (or something like it): Once you know it, you can write code in any application that supports it, which can reduce training costs. Scripting offers similar advantages. Some common scripting languages are JavaScript, VBScript and Perl. If an application allows users to develop their own reports through scripting, there may be no learning curve (assuming the developers/users know scripting), as far as the programming goes. Users simply need to know how to access the data within the OHS system.

Of course, if an OHS vendor offers an internal report writer that uses a proprietary language, there are additional training issues involved. Someone would need to learn the language before the software could generate customized reports.

Reporting Options External to the System

Some OHS vendors take the approach that reporting tool software companies have already invented the wheel. To them, it doesn't make sense to re-invent such tools within their application. Assuming access to the database is "open," an experienced user can access the data, query it, format it, and generate reports using a particular reporting tool. There are several such report writing tool vendors: Brio Technology (, Business Objects (, Hyperion ( and Seagate Software (, to name a few.

The most common method to make an application "open" is by assuring there is an ODBC (Open Database Connectivity) driver available for the OHS software database. ODBC is a Microsoftdeveloped programming interface that makes it possible for applications to access data from different database management systems. Virtually every database manufacturer offers an ODBC driver for its databases, and most reporting software vendors offer ODBC as a connectivity method to access the databases from within their tools. This prevents applications that need to talk to databases from having to write interfaces for each different database out there. They simply write the interface for ODBC, allowing them to talk to many different databases.

With the external reporting system approach, someone simply would need to learn one reporting tool, then use it to access data from an OHS system or any other application with the ability to expose itself to external applications. If an organization hasn't standardized on a particular tool, the external reporting system approach might actually be a disadvantage. Someone still may need to learn a new piece of software.

Where's the Data Coming From? It is important to consider where report data needs to come from. If an organization has taken the piecemeal approach to OH&S software--business units purchase their own software without regard for what other business units do--it can be difficult to virtually impossible for someone to extract data from the different systems for reporting purposes. They are generally in different databases and could be difficult to access, depending on where they reside.
If you want to run a report that needs to correlate safety and medical information, which resides in two or more different systems, there is probably some common information that both systems need (e.g., personnel and location information, as well as other common codes). In the piecemeal approach, the "common" information is out of sync the instant someone makes a change to the data in one of the systems. Generating a report with the data in such a state could yield inaccurate information, which is probably not desirable when federal, state, local, and organizational entities rely on the information.
Taking an integrated OHS software approach solves a lot of the problems associated with redundant, out-of-sync data. Common information resides in one place. It is easier to access related data and generate reports if the data are all in one integrated system, as opposed to in several independent systems.
Where Does the Information Need to Go?
Before writing reports, it is important to understand where the report ultimately needs to go and, if it's an electronic report, in which format it needs to be saved. In the "Internet Age," reports may not result in a printed piece of paper, but something that is automatically e-mailed or posted on an Internet or Intranet site.

Some government agencies accept reports electronically. It is vital to check with the particular agency to find out their specific requirements for electronic submissions before developing the report. Perhaps the same report needs to generate information in several formats (e.g., one for government submission, one as an e-mail, and one for the organization's Intranet).

You may need to e-mail a report as a Microsoft Word document attachment. Ideally, you could use a reporting tool to generate Word and other common format documents. One way to do that is by communicating to Word from within the report writer. Two such communication methods are Dynamic Data Exchange (DDE) and Object Linking and Embedding (OLE), Windows technologies that allow applications to communicate with one another in several ways. Through DDE and OLE, you can send commands for execution in, send data to or request data from another application. Following is a sample Word document that is automatically emailed to an employee and his or her supervisor after an audiogram:

Let's say you need to generate an Excel spreadsheet with safety statistics by site every month. By using a report writer that supports DDE, you could write a report that automatically queries various databases and sends the data to an Excel spreadsheet for posting on the company's bulletin board, as well as on its intranet site.

If you know the different output destinations and formats beforehand, you'll be able to develop the report while considering special handling that might be needed. If the content is essentially the same but needs to be generated in different formats, possibly you can use the same report logic, eliminating the need to write three different reports.

Who Needs to Access It and How?

Although the Transaction and Code Set Standard is one standard, there are actually two parts to it: 1) transactions and 2) code sets. Transactions refer to the electronic exchange of administrative and financial health care information. A Code Set, as defined by HIPAA, is any set of codes used to encode data elements. For example, a Code Set could be a list of medical diagnosis codes or medical procedure codes or a table of terms. ICD-9 is a commonly known code set. 


If many different people within an organization need to access information that a report generates, the easiest way to disseminate it might be via an intranet or Internet site. This makes getting the information in front of everyone as simple as putting the report file on the appropriate server and, "voila," everyone can access it. If the report's information is sensitive and deemed inappropriate for availability to all, you or your IT people could implement a secure area on the intranet site. Then, only those with the appropriate permissions can access the secured area.

Also, you can send the report as an e-mail message, making it available only to designated recipients. Keep in mind that if you send an e-mail with a file attachment, you'll want to be sure the recipient has a mechanism for viewing the document. If a Microsoft Word document is sent to someone who uses WordPerfect as his or her word processor, for example, he or she may not be able to view the attachment.

If you want to make a report available on a Web site, keep in mind the format in which it will be posted. Different browsers may display the same document in different ways. Microsoft Internet Explorer and Netscape Navigator are the two most popular browsers, with market shares of 86.08 percent and 13.9 percent, respectively, but there are actually thousands of different browsers in use on the World Wide Web.

The basic language of the Internet is HTML, or Hypertext Markup Language. HTML is the language that allows your browser to interpret and display a Web page. If a report is created as straight HTML, however, there is limited control over format and layout. There are other Web technologies out there that give you more control (e.g., Dynamic HTML, Macromedia Flash Player, to name a couple), but they can be more proprietary. They also provide even less consistent support across browsers. HTML is the best way to make a Web page visible from the largest set of browsers. If your organization has standardized on a particular browser, it is easier to decide in what format the report should be.

Another way to publish a report to the Web is by using the Adobe® Acrobat® PDF format. Anyone who wants to see the Acrobat file in his or her browser would need the Acrobat Reader&trade, which is free for downloading at Some organizations use this approach because it makes it more difficult for people to make changes to the report. Someone viewing an HTML report, for example, can easily view the source code for the page, modify it, and with the wave of an electronic magic wand, "improve" their safety numbers. Generating the reports as PDF doesn't allow this sort of thing to happen easily.

The concept of a Web portal has received a lot of press lately. A portal, according to Merriam- Webster's Collegiate Dictionary, is a door or entrance. Think of a Web portal as your entrance to the Web. Most portals are customized sites (based on user preferences) that can be thought of as a dashboard, providing you with a place to view information that you deem important. You can set up a portal to show information from various sources (sounds like a report, doesn't it?). For example, your portal may show safety statistics by site for the current month, a breakdown of the types of incidents that have occurred, which sites aren't meeting their safety goals, and much more.

Typically, a lot of behind-the-scenes work needs to take place in order to present the information in a portal. Data need to be extracted from several sources, combined, massaged, formatted, and, finally, displayed before any of the magic happens.

There are many different ways of getting meaningful information out of an OHS system. This article was intended to provide you with a better understanding of what the options are and what you should take into consideration before the process begins.

About the author:  Peter Singer ( is VP-Product Development at DataPipe USA Inc., a New Jersey-based firm specializing in occupational health, safety, and environmental information management systems. The company develops and markets DataPipeTM software.

New Page 1


DataPipe Overview

History of DataPipe USA

News and Events

Awards and Certifications

Helpful Websites

Employment Opportunities

Article and Newsletters


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


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