Challenge Overview
Project overview
The Healthcare Fraud Prevention Partnership (HFPP) has asked TopCoder to build a data exchange network that will be used by partners to identify suspicious insurance claims. Each partner is a healthcare insurance company with its own database of claims, which it makes available through a network node.
A study is a plan to search for claims meeting certain criteria so that they can be analyzed further. One network node is operated by a Trusted Third Party (TTP), the sole entity which is authorized to execute studies. The TTP users input and execute studies with a web application called the study management system. The user flow of the study management system has been defined and prototyped in HTML.
Task requirements
We are seeking a direct-to-assembly architecture for the study management system, which is to be implemented as a Django application. The underlying language is Python 3.3 and the backing store is SQLite. The application framework offered by Django is to be used as much as possible to simplify development. This architecture is expected to lead directly to one assembly contests or several concurrent assembly contests, whichever seems more practical.
Attached to this contest specification are several UI prototypes that define the front end of the study management system. These UI prototypes are currently being integrated into a single HTML package and will have to be subsequently enhanced according to the specifications given further below. The general user flow of this app has four phases, each corresponding to one of the main tabs in the basic UI prototype. The four phases are the following:
- Study input (tab label: Draft): Build a query to define the set of claims that are to be requested from partners.
- Study execution (In progress): View information about ongoing data transactions, i.e., data requests and data responses.
- Data analysis (Completed; rename to Analysis): Filter the data with additional queries, and generate statistical graphics.
- Permanent record (Archived): Contains information about the study, including an automatically generated PDF summary.
Study input
The UI prototype for the query construction page is attached. Please see New_Study.html and Edit_Study.html in build.query.tar.gz. We will add a multi-select menu to let the user select a set of partners to whom data requests will be sent. Partner management will be done with a new page (see Partner.html in manage.partners.tar.gz) which is to be integrated into the app.
Before sending the query through the data exchange network, the study management application will call an external function that transforms the query into a secure database query description. This external function will be designed and implemented in a separate contest. You are only responsible for interfacing with it.
Architecture documents for the HFPP network node are attached in the contest forum. The study management application will use a node instance to send data requests and receive data responses.
Study execution
During this phase, transaction statistics must be displayed as shown by the UI prototype. Architecture documents for the network hub are attached in the contest forum. The phase ends when all data requests have been answered or the user manually finalizes the transactions, whichever occurs sooner.
Data analysis
After the data transactions have ended, the received claims are aggregated and displayed in a table. The user can filter claims using a query constructed in the same manner as the original study query. The user also has the option of generating summary graphics using tools that have been separately prototyped. Please see Study_Details_Completed.html in visual.analysis.tar.gz.
Permanent record
At the end of data analysis, a study report is generated in PDF format. It will include a textual summary entered by the user in the report generation dialog. It will also include the subset of claims identified by the user as potentially fraudulent, together with a selection of charts chosen by the user.
User management
One more page that has not been built yet will allow an administrative user to add, delete, and modify user accounts. The page will be built according to the results of this architecture contest. You must include assembly instructions that incorporate the future HTML prototype into the overall application.
Final Submission Guidelines
Software environment
- Django 1.5 running on Python 3.3
- backing store: SQLite
- the copilot's permission is required for any additional libraries
- Ubuntu 12.04
Deliverables
- standard deliverables for module assembly
- architecture must lead directly to one or several concurrent assembly contests