Challenge Overview
Project Overview
The Healthcare Fraud Prevention Partnership is a collaboration between government and private insurers to combat healthcare fraud. A government committee (DARC) will decide on studies and send them to a trusted third party (TTP) for execution. TopCoder is building an entire system for executing studies. A study is a plan for collecting data from the network of partners and analyzing the data to identify potential cases of fraud and waste.
The three major layers of the HFPP system are detailed on a wiki page. Currently we are dealing with the study management software, a web app at the front end of the system that includes, among its other functionality, a facility for entering a study. This contest is concerned with defining the technological requirements and internal logic of a business rule system for expressing studies.
Module Requirements
You are responsible for the portion of the user interface in which the TPP user enters a set of business rules to define the study. The winning Idea Generation submission on this topic suggested a specific business-rule technology, but you are not required to abide by that choice. You may propose any technology that is freely available and liberally licensed as long as it can meet the client's stringent requirements for data security:
The business rule module must be configured so that it can be used to express three sets of constraints in executing a study:
- partner selection: Which partners are we asking to contribute data to the study?
- data retrieval: When the data request arrives on the partner's premises, what data should they retrieve from their databases?
- data aggregation: Once the data responses have come back to the TTP, how do we merge it and filter it for the purpose of the study?
Apart from describing the choice of business rule system and its technological requirements, the bulk of your submission should be devoted to defining one or more domain-specific languages (DSLs) to address the needs above. We expect to see you demonstrate your DSL in plain text on one or more fraud scenarios described in the Conceptualization document. All other user interaction is out of scope.
Deliverables
- Application Design Specification
- succinct explanation of security compliance
- DSL definition with demonstrations for all three use cases: partner selection, data retrieval, data aggregation
- a brief tutorial on using your DSL to express studies
Final Submission Guidelines
- any freely available, liberally licensed software platform
- compliance with HIPAA and FISMAA