IQware's Approach to Application Development & Deployment

Application Development

The Rule Processor (RP) is what reads & executes rules. These rules contain the parameters for the events and actions that comprise the rule. Rules are of the form "upon event(s), take action(s)". Mathematically, rules are of the form "if f(ei) then do g(ai)" where { ei } is the set of allowed events and {ai} is the set of allowed actions. The events and action definitions are sufficiently general to handle a wide variety of "business process flow" requirements. The event-action pairs are orthogonal so that any event(s) can cause any action(s) to be taken - no limitations.

The Rule processor uses the "Reference Monitor" security rules where required for proper enforcement. A portion of the rule parameters contain "O/S permission" parameters, "users allowed" parameters and "access mode" parameters. The security processing is done in one place so that it is easy to test, verify and modify.

IQware has a utility, called IQ Build, that sets up the rules. IQ Build is an object-oriented graphics editor that is "WYSIWYG" so that the application appears as you would like it to appear as you build it. This graphics editor is the main tool for creating an interoperable, secure, rule-based, centrally managed application.

IQware's "rules" are like letters of the alphabet. Letters are the basic building blocks from which words (and by extension language and meaning) are created. The alphabet of the English language has not changed for hundreds of years, but new words are constantly being created and meanings are constantly evolving.. For example, the phrase "disk drive", nonsensical in Shakespearian times, has a concrete meaning to today's audience - no new letters had to be invented in order for the phrase to gain meaning. IQware has all of the letters (rules) necessary to create new phrases or functionality, they only need to be configured to meet your needs. Because of this patented (US #7,322,028) rule-based process, IQware meets the changing needs of any business in a cost-efficient, timely manner.

IQware's rules are categorized according to function. The functional categories of items that are governed by rules are the following:

1. Object/Screen display
2. User interface (UIF) object rendering and control
3. Database operations
4. Data acquisition
5. Data analysis
6. Data transfer (from anywhere to anywhere)
7. Report preparation, formatting and output
8. External O/S actions (e.g., run a job, execute command procedure, etc.)

Rule elements are grouped into eleven (11) classes. Classes 2 through 11 each require a parameter list for complete specification of the parameters for the rule. The "summary" class does not require a parameter list.

1. Summary (format, ID, location, status, next)
2. Event(s)
3. Action(s)
4. Data Source
5. Data Destination
6. SQL Source
7. SQL Destination
8. O/S Permissions
9. Access Modes
10. Users Allowed
11. Audit rules

Application Deployment

Rules are run in a separate program, Rule Processor (IQ_RP). Rule processor allows you to interact with the rules as defined in Build. One of the hallmark features of IQware's patented (US #7,322,028) rule-based software is that changes can be made "on-the-fly." Changes in process do not have to be re-coded, re-compiled, re-tested, and "re-debugged". Instead, rules need only be reconfigured or added. Once configured - a process that is complete in a matter of moments - the rule is fully-functional. The user does not even have to log out of his or her session in order to implement the new function.

Using IQware Software

Because this rule-base architecture is new, an example of how IQware functions in the real-world is beneficial. IQware automates your business process using Build Utility and Rule Processor.

One Example: Designing a Medical Therapy Management System Using IQware

The process of designing an interface using Build begins with the IQware team creating a process flow chart incorporating all of the aspects of your business process. Two examples which require process flow charts (pictured below) are actions required to perform a Medication Therapy Review (MTR) session (left) and billing for pharmacy activities (right). These actions include gathering a patient's medical information and assigning proper billing codes among many other activities necessary for auditing and regulatory compliance.

IQ Build creates an interface incorporating all of the attributes of the business flow chart. Each screen consists of a variety of symbols, some of which are rules, each of which can be configured and re-configured "on-the-fly" based on the changing needs of the client. Functionality, as well as other attributes like size, position, and color, can be reconfigured using IQware's Build utility without the need for reprogramming or system down-time as regulations and businesses processes inevitably change.

Configuring Rules

As another example, rules may be edited on the completed MTR screen (see below, outlined in red and numbered) to alter functionality, thus eliminating the need for reprogramming or upgrading to a different software version.

Examining the four rules associated with beginning a new MTR session provides a good example of the flexibility of application built with the Build Utility. The four rules are as follows:

• Rule 15 produces the above Data Entry Box (DEB) prompting the pharmacist to enter information about a patient's current MTR session. This is the only rule associated with this action that is visible to the end user.
• Rule 65 states that when the user clicks "OK" on Rule 15, patient information is retrieved from the database and stored internally for use during the session.
• Rule 75 states that when the information is retrieved for Rule 65, a different piece of patient information is retrieved from the database, also stored internally for use during the session.
• Rule 66 states that when Rule 75 is complete, all of the information regarding the new session is stored in the database. This step ensures that the database records are saved every time a new session is started for a patient (for auditing, billing, and regulatory compliance).

The end user is only required to click onto the screen one time in order to execute all four of these rules. If the parameters for starting a new session or the amount of information the pharmacy would like to store regarding a new session changes, you would only have to alter one of the rules, or simply add a new rule anywhere on the screen to make this change - the physical location of the rule plays no role in the functionality, only the rule configuration matters.

This same principle can be applied to to screens for any application.

Using Rule Processor

The appearance of the screen in IQ_RP is identical to that in Build, with the exception of the lack of menu bar at the top of the window. In the MTM example, the pharmacist sees the following screen:

The rules are executed by completing actions as specified in Build. For instance, Rule 15 (as discussed above) states that "On Mouse Click, Use DEB" (the DEB has four rows and two columns). Therefore, when the user clicks on the rule (labeled "New Session"), a 4 row by 2 column DEB appears:

Functioning rules that do not specify the action "On Mouse Click" cannot be initiated by the user. Instead, those rules involve retrieving, transferring, and/or arranging information either stored internally for use during the session or externally in the database.