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 (
msdn.microsoft.com/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 (www.brio.com),
Business Objects (www.businessobjects.com), Hyperion (www.hyperion.com) and
Seagate Software ( www.seagatesoftware.com), 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.
Transactions
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 www.adobe.com/products/acrobat/readstep.html. 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 ( petes@KnorrAssociates.com) is
VP-Product Development at Knorr Associates Inc., a New Jersey-based firm
specializing in occupational health, safety, and environmental information
management systems. The company develops and markets DataPipeTM software.
