Healthcare Fraud Prevention - Boolean Query Wireframes

The Healthcare Fraud Prevention Partnership will execute studies to look for fraudulent healthcare insurance claims. One of the early steps in the process of executing a study is selecting a subset of claims that will be requested from partners. We have already visualized a simple method of claim selection. We are seeking wireframes for a more sophisticated claim selection screen that incorporates the concept of boolean queries.

Round 1

Wireframe all functionality described below.

Round 2

Revise and refine your wireframes in response to checkpoint feedback.

Overview

We are building a web application that handles all aspects of executing a study. At the start of study execution, a user defines a subset of data that will be requested from network partners.

The attached PNG images show a concept for organizing claim attributes into four categories and using them to select a subset of claims.

• date attributes: select by date range
• medical code atttributes: select by code pattern
• ID attributes: select by ID pattern
• amount attributes: select by range of monetary value

We would like you to wireframe a new and improved UI that builds on the existing concept.

One of the important concepts we want to add is the construction of logical relationships between selected attributes. We want to add three types of relationships:

• the and relationship, also called logical conjunction
• the or relationship, also called logical disjunction
• the not relationship, also called logical negation

The remaining requirements have to do with refining the existing concept as detailed below.

 

Requirements

Our preference is to see the required functionality wireframed in a single screen. You may add pop-ups and tabs if you wish, but we'd like to minimize the number of tabs.

In the provided images, you see the claim attributes listed by category. We would like to improve on this by letting the user list the attributes in two ways:

• list by category
• list by alphabetic order of attribute name

Note that the images show only one attribute being selected at a time. That is inaccurate. We want the user to be able to select many attributes at once. There should be a visible difference between attributes that are being selected and those that are not.

The user should be able to view attributes in several ways:

• show all attributes in compact form, with selected attributes marked
• show all selected attributes in expanded form, with editing fields visible
• show only selected attributes in compact form
• show only selected attributes in expanded form

In the current concept, there is no obvious way to select only one limit for a date range or monetary value. These are now required features:

• for a date range, specify only a start date or only an end date
• for a monetary value, specify only a minimum or only a maximum

The current concept does not indicate any logical relationship between multiple selected attributes. We are asking you to come up with a way to show these relationships.

• not: this is a unary operator; it selects claims for which the specified criterion is not true
• or: this is a binary operator; it selects claims for which at least one of the two criteria is true
• and: this is a binary operator; it selects claims for which both of the criteria are true

Note that there may be several criteria for each attribute. For example, the user may select several ID patterns for "Attending Physician ID". Each pattern is a separate criterion that may be joined with another criterion in the same attribute or from another attribute.

The final requirement is to allow the user to group logical relationships. This is necessary in order to apply a sequence of logical relationships. For example, suppose the user wants to join three criteria with the or relationship. This can be done by grouping two criteria, then adding the third one. The following groupings are equivalent:

• (A or B) or C
• A or (B or C)

However, the order of grouping is significant when logical relationships are mixed. For example, the following are different:

• (A or B) and C
• A or (B and C)

That is why grouping is important.

 

Target audience

Healthcare management professionals who are not necessarily IT experts.

 

Judging criteria

Completeness: Do your wireframes meet the requirements?

Ease of use: Is this a user-friendly layout?

 

What to submit

Submission zip: HTML wireframes.

Source zip: Project files.

Preview image: 1024 x 1024 screenshot, JPEG or PNG.

 

Final fixes

You may be asked for minor changes to meet the stated requirements of this contest.