Challenge Summary
The Healthcare Fraud Prevention Partnership (HFPP) is a U.S. government initiative to share data among health insurers in order to detect fraudulent reimbursement claims. The front end of the data exchange network is a web app that allows certain users to input and execute a study, which is a plan to collect and analyze data. You are responsible for wireframing the general user flow and two major processes:
- entering the data requirements to execute a study
- analyzing the data responses after the study has been executed
Round 1
Complete wireframes for all four work flows:
- General work flow
- Input a study
- View transactions
- Analyze study responses
Round 2
Revise and refine the wireframes in response to checkpoint feedback.
Overview
The attached Conceptualization document provides background information about the HFPP. To understand the terminology of healthcare insurance, review the definitions at the end of section 1.1.
The front end of the data exchange network is a web application that allows Trusted Third Party (TTP) users to input a study that was formulated by the Data Analysis and Review Committee (DARC). The study arrives in the form of a plain English description. It is the TTP user's responsibility to enter the study in the form of business rules, which define the data points to be collected for analysis.
Your wireframes will describe a web app that is used by TTP users to input and execute a study.
You are required to cover the following work flows in section 3.3 of the Conceptualization document:
- General work flow: all of process map 1
- Input the study: all of process map 2
- View transactions: the first and last steps of process map 3
- Analyze data responses: all of process map 5
In covering these requirements, you may organize the work flows into the number and order of pages that you find to be efficient and user-friendly.
General work flow
The web app is intended for a TTP user. DARC is an external entity that sends a study to the TTP user for input and execution. The main phases in the general work flow are expanded into other process maps and described in detail further below.
Logging is a system process; you do not have to cover it in your wireframes.
Input a study
The TTP user inputs a study in business rules like these: Drools Expert Examples
A business rule is a logical description of requested data. It specifies constraints that are to be evaluated against a piece of data to determine whether it satisfies the request. Thus, a set of business rules will describe a set of data that must be collected for a study. Later, the user has the option of writing a different set of business rules to help with filtering and analyzing the data responses.
Rules are entered in two ways:
- textual code editor: allows the user to write rules in a declarative language
- visual rule wizard: like the guided rule editor shown under "Interactive Debugging"
The user can work in either representation and may switch back and forth. The exact interfaces employed by the code editor and the rule wizard will be defined separately, so you do not have to wireframe them here. Mock them up as black boxes and wireframe the user flow of switching between the interfaces.
View transactions
The user has the option of observing data transactions in the network. This takes place after the study has been entered and the data requests have been sent out. If the user wishes to follow the transactions, the following information is displayed:
- pending data requests: sent to a partner and no response received yet
- declined data requests: a partner has declined to contribute data to the study
- satisfied data requests: a partner has responded to the request with data
- response rate: the proportion of pending data requests that have been satisfied so far
- reciprocity per partner: the ratio of data requests received to data responses sent by each partner
Analyze data responses
The TTP user can analyze the data responses in the form of a list displayed on the page in fixed rows and columns, much like a spreadsheet. In addition, the user can inspect individual claims in the list or prepare visual summary statistics.
- Aggregation: Incoming data responses are listed in a spreadsheet style.
- Manual inspection: The user selects individual claims, expanding them into a detailed format.
- Visual analysis: The user generates a bar chart, pie chart, or scatter plot from the data responses.
- Analysis with business rules: The user applies a new set of business rules to filter claims further.
After analyzing the data, the user decides which claims may indicate fraud or waste. These claims are gathered in a report which will be shared with DARC and with network participants who contributed to the study. Note that claims are anonymized in the report: the identity of the partner that provided each piece of data is stripped out of the results.
Target audience
Healthcare management professionals who are not IT experts.
Judging criteria
Completeness: Do your wireframes map out the required work flows?
Ease of use: Is this a user-friendly application 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.
Please read the challenge specification carefully and watch the forums for any questions or feedback concerning this challenge. It is important that you monitor any updates provided by the client or Studio Admins in the forums. Please post any questions you might have for the client in the forums.