Challenge Overview
System Overview
The Healthcare Fraud Prevention Partnership (HFPP) is building a network to exchange data between health insurers to detect and prevent fraud. An essential requirement is that data must be stored individually on each partner's premises, not centralized in a warehouse. The data exchange network must be decentralized and secure, and it must encourage reciprocity in sharing data.
The process of collecting and analyzing data is encapsulated in a concept called the study. Each study is a plan to answer certain questions about healthcare reimbursement claims that have been submitted to health insurers who are partners in the HFPP.
The front end of the HFPP system has a study management interface that is currently under development. In the initial version of the HFPP system, studies are designed by an external committee and delivered to a trusted third party (TTP) for execution. The TTP user enters a study in the form of business rules that express the following constraints:
- which partners are being asked to contribute data to the study
- what data is requested from each partner's database
Upon receving the data requests, partners who agree to contribute to the study retrieve the requested claims and transform them into a standard XML format using a conversion module that is currently under development. The data exchange network will take the output of the conversion module and transmit it to the TTP for aggregation and analysis.
In the current contest, you are responsible for the architecture of the data exchange network. Features that belong to the study management system and the data conversion utilities are not in scope. To understand what part is in scope, please refer to the Conceptualization wiki and review the requirements listed for the data exchange network.
Data Format
Claims are stored by each partner in their own database in a format of their choosing. We are developing a proof-of-concept conversion module that transforms claims from a particular CSV format to a standard XML format. All future versions of the conversion module will also convert claims to XML. Thus, the HFPP network will always exchange claim data in the standard XML format. You can ignore the partner's individual choice of data format and assume that XML is the starting point for network transmission. Each network node is expected to serialize and encrypt the data prior to transmission, then decrypt and deserialize it upon arrival.
The network is used not only to share claims, but to distribute reports upon conclusion of a study.
Data Exchange Network
The primary requirement for the data exchange network is decentralized storage. Partner data will be stored on each partner's premises, not in a central warehouse.
Further network requirements are as follows.
- data reciprocity: transactional reciprocity is not required, but HFPP members should share data in the long run
- caching of frequently shared data
- FISMA-compliant security standards; see the Risk Management Framework for details
- HIPAA-compliant data handling safeguards to ensure privacy for healthcare providers and patients
In addition to consulting the client questionnaire, please refer to the attached concept for the data exchange network. The network concept stipulates the use of a central hub to provide authentication, caching, and other network management services. While partners will continue to store their own data (except cached data) to achieve the goal of decentralized data storage, the central hub assumes responsibility for other aspects of the network. Therefore, peer-to-peer networking is not required.
The network concept also includes the idea of using the AMQP protocol for distributed messaging. You may incorporate this protocol, or a version of it, into the system architecture. The use of the Qpid messaging library is acceptable, and you may ask for permission to include other external libraries. However, there is no requirement to use a specific messaging library or the AMQP protocol in general. You may substitute a network protocol of your choosing.
The ultimate goal of the HFPP project is for the data exchange network to support open requests. This means that any partner, not just the external committee, will be allowed to formulate studies. The initial iteration of the network will not support open requests, but this future goal should be taken into consideration.
Technology requirements
- the language of implementation must be Python 3
- to use a third-party library, please ask for permission in the forum or use OR to contact the copilot privately
- open standards are required, as the HFPP network itself will be an open standard
- explain how your architecture complies with FISMA guidelines for network security
- explain how your architecture complies with HIPAA requirements to safeguard private healthcare information
Final Submission Guidelines
Deliverables
A small proof-of-concept implementation or "walking skeleton" is required. The language of implementation must be Python 3 for the walking skeleton as well as the network in general, with the possible exception of third-party libraries that offer a Python 3 API to a code base compiled in a different language. A walking skeleton is defined as follows:
- A simple proof of concept to validate the architecture.
- A low-functionality working system to which more functionality can be added incrementally.
- Coverage of the entire network stack, implementing the smallest and simplest code that meets the network requirements: decentralized storage, caching of frequently shared data, measurement of reciprocity.
The following is also required:
- standard deliverables for System Architecture, including sequence diagrams and interface diagrams