ЕСОЗ - публічна документація
Fraud detection Scope
Fraud Detection
The main goal of the Financing Reform of MoH is to change the payment model for medical facilities and the doctors. The very first step is to implement the financing reform for the primary health care/ for physicians - the salary rate will be calculated on the basis of the number of declarations signed between the doctor and the patient. The experience of other countries shows that there will be attempts to manipulate the data - falsification the number of patients for increasing the salary rate. The main goal of the Fraud Detection mechanism is to provide a possibility to identify and prevent possible financial losses due to fraud activities.
The main risk that can cause financial losses is intentional increase of the number of signed by doctor declarations that can be done in several ways:
- Creation of fake patient’s data
- Creation of declaration records without knowledge and consent of a patient
- Creation of fake records in collusion with other parties.
In order to reduce the number of fraud possibilities the system has a set of automatic verifications like verification of electronic signature when on declaration creation, deduplication mechanism, developed one-time-password mechanism for patient’s verification. However, for those patients that don’t have mobile phone (for ex, old people and children) the possibility of offline authorization was developed. It is expected that during offline verification the patient’s documents will be scanned and uploaded to the system.
The system should analyze the following data:
- Number of patients per doctor
- Number of patients registered for the same phone number
- Number and percentage of patients per doctor that have set offline authorization method
- Number and percentage of patients per legal entity that have set offline authorization method
- Frequency of declarations changes per patient.
If the data differ from the average value or greater than the configured number the system should provide a notification/ alert to attract additional attention of NHS employee. Such deviations should be analyzed separately by employee.
Therefore the system should provide the possibility to detect possible fraud activities based on a set of configured rules, notify a user about the findings in a report or by other mean.
Proposed solution:
- Create Reports DB datamart with all the required data about doctors, MSP, declarations, etc. that should be used as a source for the fraud detection reports.
- Configure the real-time data streaming from the PRM DB, OPS DB, MPI DB, etc. to the Reports DB datamart. There should be no personal data in the Reports DB.
- Use BI tool to analyze data in the Reports DB and create reports to detect fraud suspicious activities.
- Responsible persons should analyze reports, do the investigation and perform some follow-up actions.
- Use the NHS admin to perform the follow-up actions in case if fraud has been confirmed. For example, block/unblock MIS, block/unblock MSP, block/unblock user, etc.
Scope Item | Description | Status |
---|---|---|
Report 1: Number of patients per doctor | M | |
Report 2: Number of patients registered for the same phone number | M | |
Report 3: Number and percentage of patients per doctor that have set offline authorization method | M | |
Report 4: Number and percentage of patients per legal entity that have set offline authorization method | M | |
Report 5: Frequency of declarations changes per patient | Descoped | |
Fraud Data Mart | Provide datasource for MoH analysts | M |
Fraud Data Mart ETL procedures development | M | |
Deploy and configure BI System of choice | M | |
Action 1: Block/Unblock User and related entities | M | |
Action 2: Block/Unblock MSP | M | |
Action 3: Block/Unblock MIS | M | |
NHS Admin portal update | Provide ability to ban/block/unblock core entities that defined as fraudsters | M |
Open questions:
BI tool to be used - Yevhen - 9/10/17
Fraud DB vs. Reporting DB - Katerina - 9/10/17
Milestones | PIC | Date |
---|---|---|
Decide on architecture | ||
Chose BI Tool | Yevhen | |
Provide report templates | ||
Actions Defined | ||
Design Fraud Data Mart | ||
Design Approved | ||
Actions Specifications finished | ||
ETL Specifications finished | ||
NHS Portal Specifications finished | ||
Data Mart Dev Finished | Alex Troush | |
Test Scenarios and Data prepared | ||
Data Mart Tested | ||
BI Tool deployed and connected | Valery Litvinov | |
Reports Configured | ||
Actions developed | ||
NHS Admin developed | ||
NHS Admin tested |
ЕСОЗ - публічна документація