Monday, June 5, 2017

Week 1: The Match Begins!

The objectives of the Patient Matching 2.0 project are,

1.  Perform patient match taking considerations of the previous run (incremental patient matching). 
  • This method will avoid unnecessary record comparisons.
  • A match will be performed upon,
          addition of new patients or
          changes in patients’ records
  • After an incremental match a separate output will be created.
  • This incremental matching is specific to a strategy.
  • An output from previous run can be selected as the memory for the next run(eg. For strategy “A” there are 50 runs in last 3 months, so it should be possible to pick one output from the 50 as the memory for the next match)
2.  Avoid repeated manual reviews of previous manually reviewed matches
3.  UI changes to reflect above functionalities

According to my project plan my first goal is to perform patient match taking considerations of the previous run (incremental patient matching).
I have already identified a method to get the work done. For my first goal the relevant tables in OpenMRS database are,

  • patient - has all the information about when was the patient added and when was the patient last updated
  • patientmatching_configuration - has the details of the saved configurations
  • patientmatching_report - has the stored strategies
  • patientmatching_report_configuration - associate table which match the table patientmatching_configuration and the patientmatching_report
  • patientmatching_report_generation_step - has the properties which should be updated as in the  incremental matching process report is going to be updated without creating some bunch of reports over and over again.
Below images are the screenshots of above mentioned tables.

patient


patientmatching_configuration


patientmatching_report


patientmatching_report_configuration


patientmatching_report_generation_step



I have identified few steps to solve this problem. 
In the code, 
  1. The strategy should be identified which the user being used.
  2. Is the strategy combination of set of strategies? If it is we ignore it. If not we should consider the particular strategy and then should follow the steps listed below.
  3. Should find out whether there are any reports stored in the database related to the strategy. If there are no reports, good to go nothing has matched earlier therefore all the patient records should be matched with each other.
  4. If there are couple of old reports related to the strategy, should be prompt to user asking which report is considered as the memory for the next run.
  5. Once after the user has selected the old report we must find the date it has been run and fetch the patients' records which are either added or updated after that date. This is done by comparing patientmatching_report.created_on AND patient.date_added OR patient.date_changed table fields.
So what I have been currently doing is the 1,2, and 3rd steps. My GitHub repo can be found here.

No comments:

Post a Comment