Skip directly to searchSkip directly to the site navigationSkip directly to the page's main content

IBIS-Q System Documentation - Overview

IBIS-PH Overview

The Indicator-Based Information System for Public Health (IBIS-PH) provides Web-based access to public health data. Developed over several years by the Utah Department of Health, Office of Public Health Assessment, IBIS-PH is a resource for public health officials, data analysts, and individuals who need to tabulate vital statistics data, track progress on Healthy People 2010 goals, and the displaying of data for local communities.

Figure 1-1. IBIS-PH Home Page

IBIS-PH comprises the following components:
  • IBIS-IRV --- This Reporting and Visualization System provides web reports of standardized views, and can be used to proactively present information to the public.
  • IBIS-Admin --- The Indicator Report Development and Administration Interface allows subject matter experts to publish indicator pages within IBIS.
  • IBIS-Q --- This interactive query system enables users to query public health datasets directly.

IBIS-Q from an End-User's Perspective

Members of the general public, health care workers, government officials, educators---anyone who needs to access public health statistics on a variety of issues---can locate this information through IBIS-Q. All the person needs is access to the Internet. Any user with basic knowledge of a web browser can readily maneuver through the steps necessary to set up his or her customized query of the available datasets.

Clicking on the Custom Query tab on the IBIS-PH home page takes the user to the Custom Query Main Page, or the IBIS-Q interface. Alternatively, a user can take a short-cut to the query setup directly from the drop-down menus on the Custom Query tab, as shown in Figure 1-2.

Figure 1-2. IBIS-PH Custom Query (IBIS-Q), Drop Down Menu from the Home Page

In formulating a query on the Health Surveys/BRFSS dataset, the user is first presented with an option for making 'Quick Selection' or an 'Advanced Selection.' In both cases, the next screens provide the opportunity for specifying the measures and type of display the user wants to see. Figure 1-3 shows a portion of one of the "steps" screens. Default selections are supplied for each step.
Figure 1-3. Selecting Filters

After selecting all filters and clicking the Submit button, a Confirmation page is returned (or may be turned off, if desired) enabling the user to review his or her selections, change them, or create a new query. However, if the user confirms the original selections and presses the Submit button, the query is processed through the backend of the system and results returned.

In summary, end users are presented with a few simple, well-defined sets of choices to make on each screen. Each choice, in turn, results in a new screen that enables further definition, or drilling-down, of specific parameters. At any point, the user can backup or completely opt out of the process and start an entirely new query or readjust selections in the current query. The time lapse between pressing the Submit button on a query and receiving a Results page back is negligible. The ease and the speed with which queries can be posed encourage user interaction with IBIS-Q.

IBIS-Q from a System Perspective

IBIS-Q is built on a three-tier architecture that includes the Web server, the IBIS-Q Application server, and the Statistical Analysis Software (SAS) server.

The IBIS-Q query pages are served by the Web server. The "steps," which guide the user in selecting filters for a query, are driven by the Module XML files created by the administrator. As the user selects filters (or accepts the defaults provided), those selections are translated into a URL through underlying templates and javascript. Once the user confirms the selections and presses the Submit button, the application server creates a query string that is sent to the CGI application in the SAS server.

A configuration file translates the query string and applies a specific function file definition to compose the SAS commands. A SAS template for this query request is created.

A program called HI-IQ ( ) calls SAS, which runs the procedure against the appropriate dataset. Results from SAS are returned as XML (eXtensible Markup Language)-tagged data, which is joined with a header and tail xml file to form a complete output packet.

The interface combines the completed data output with an XSLT output template to display the results to the user as an html page.

The user interface uses the XML document files to store the page definitions and controls needed to build the pages presented to the user. An XSLT (XML Stylesheet) is used to transform the XML control definitions into an HTML page that the user can interact with. This approach allows module developers to create SAS programs and module definition files and to not have them focus on HTML and Javascript coding.

Figure 1-4 shows a simplified view of the system components involved just in the user interface portion of IBIS-Q.

Figure 1-4. System Components of the User Interface

Overview of IBIS-Q Administration

Queries are based on specific datasets. Therefore, the functional basis of IBIS-Q is its access to those datasets. That access is enabled, in part, by the XML modules the administrator creates. A module is a set of indicators based on one specific dataset. Further delineating the modules and indicators are the configuration (cfg) and function (func) files, which describe where the HI-IQ application can locate the information on the dataset.

The cfg files describe where the dataset is located and what the dataset looks like. The func files describe the measure or specific statistical analysis to be applied.

As the IBIS-Q administrator, you have the following basic responsibilities:
  • Understand the system environment.
  • Understand the particular data needs of your users.
  • Understand data reporting, survey reporting, and system updating schedules.
  • Establish and post regular updating cycles, with mandatory yearly updating.
  • Create, test, and maintain the Interface XML files.
  • Draft help documentation as needed.
  • Understand the back-end processing environment sufficiently to communicate requirements to software developers.

Figure 1-5. Overview of Setting Up A Page

Prepare data for use
  • Prepare SAS data
  • Create configuration files
  • Create func files
  • Create label files
  • Create module.xml files

Prerequisite Set Up for IBIS-PH

The directory structure and file naming conventions described in the remainder of this document assume a particular hardware and software system set up. The following information describes the working environment and recommendations for using IBIS-PH within the Utah Department of Health.

Hardware Required for IBIS-PH
Different parts of the system reside on different servers. Utah Department of Health hosts IBIS on several multi-process Sun Unix machines that also support other applications.


It is possible to host IBIS on a single machine, but the system is equally well-suited to being hosted on multiple machines in a distributed environment. Within a distributed environment, the characteristics of the underlying LAN and WAN are important factors in overall system performance. Any of the current hardware server platforms that support the hardware listed below are acceptable.

The minimum single-server specifications for light to moderate system usage [define "light to moderate" in terms of access or usage] is a Pentium 4 with 512 MB of memory and a fast [???] disk I/O subsystem.

Data Storage Capacity

The web server itself, or a machine accessible by the web server, needs to store large volumes of data. The Utah IBIS-PH currently uses about 20 GB of storage, 10GB for IBIS-Q and 10GB for IBIS-IRV.

Software Required for IBIS-PH
Running any portion of IBIS-PH requires the following software components:
  • Internet Browser
    Netscape and Microsoft Internet Explorer have been tested, and both work. In the experience of the Utah system, Internet Explorer does not require as much specificity in the interface programs, but either browser works.
  • Web Server
    IBIS-IRV uses Apache or any other web server that supports a Java application server. IBIS-Q can be used with any CGI-enabled (Common Gateway Interface) web server, such as Microsoft Internet Information Service.
  • Java Application Server
    For IBIS-IRV production, Utah uses Sun iPlanet; for IBIS-Q and for development, Utah uses Tomcat. However, the system works with any application server that supports Java servlets, JSPs, and JNDI using JDK 1.3+ (does not have to be complete EJB, J2EE).

Additional Software Required for IBIS-Q: SAS
The SAS/Base System module produces most of the queries, but SAS/Stat version 8.2 or later is needed to process complex survey data such as BRFSS. SAS must be licensed to run on the web server. (Web servers running Unix require the SAS license for Unix.) The IBIS-Q application is SAS-ready, but can be adapted to run with other statistical packages. Developing and testing those adaptations require additional time and resources and are not discussed in the IBIS-Q documentation.

Files Needed to Run IBIS-Q
The following files are listed with the assumption that the IBIS-Q application is running on an application server with a licensed version of SAS (SAS/Base and SAS/Stat modules), and it has a front-end consisted of one or more web pages with a link to the query module. Utah provides the following files as a base for running IBIS-Q:
  • Hi_IQ_Func (Executable file, C program)
  • IBIS-Q Interface XSLTs
    • Module set XSLT
    • Module Selections XSLT (Query.xslt)
    • Module Submit Query XSLT
    • Module Get Query Results XSLT
  • Javascript Files
    • Query options
    • Display default on steps
    • [???]

Locales outside of Utah that want to use IBIS-Q need to maintain their own versions of the following interface files:
  • Module Set XML files (module set and measure selection)
  • Module Selections XML files (one for each query request interface
  • Configuration file (query.cfg; one for each dataset; one configuration file can serve multiple modules)
  • Function file (func1.def; one for each measure, such as death rate, age-adjusted death rate, hospitalization rate, survey percentage, etc.)
  • Label file (one for each variable)
  • Header file (ibisq_head.xml; one for each measure)
  • Output label file (ibisq_out.xml; one for each measure)
  • Help files (additional web pages to which users may be directed for extensive help; short help messages can be contained within the Module XML files.)

In addition, SAS requires a SAS dataset for each module, and SAS code for both routine and annual preparation of SAS datasets from source data.
The information provided was retrieved on: Sun, 24 October 2021 21:10:03.

Content updated: Thu, 21 Feb 2008 00:50:33 MST