What’s new in patient matching module 1.2.4

Here are the list of features added to the Patient Matching module version 1.2.4

The reports files are saved to database

The reports generated by de-duplication process were stored in flat files in previous versions except the report metadata (time taken to generate, date created..)

With the new release the report files are stored, used in the database with the data (patients, strategies...) linked to records in the database. That has made the reports easy to store and use with the benefits of relational database over flat files.

The strategies no longer use flat files

The strategies were stored in databases earlier, but they were not used in de-duplication process. The same copy of data which had been saved in the file system (inside config.xml) was used instead of the data in the database. With the new release the configurations are no longer saved to files nor they are used from the file in de-duplication process. Instead the strategies will be only saved in database and they will be used from the database.

Automatic migration of old reports and strategies

Although the new reports and strategies are stored in the databases, the reports and strategies created with older versions of patient matching module were still in file system. So the old reports and strategies also needed to be migrated to the database. It was implemented to be done in the module activation stage.

The user was not given an option not to migrate the data. If the user was given that option, it would have made the module to have code to manage both the data in the file system and database. However the old reports and the strategies that were migrated to the database were backed up and left unchanged in case of later needs.

The user is provided an estimation on the strategies when the user create/edit strategies.

The user can select any field combination the user like as an strategy. But depending on the data, this selection can sometime lead to a large number of comparisons which become resource consuming. And also the selection may sometime lead to a very few or no comparisons which is again not useful. To avoid these situations the user was provided with a rough estimation on how much pairs the strategy will consider for identifying possible duplications. This is based on user’s selection of “Must Match” fields when the strategy is created. For example, if the user select the family name as a must match field the estimations will show the number of patient pairs that has the same family name. Depending on these estimation the user can either proceed and save the strategy or if the user is not satisfied he/she can go back and edit the selections and retry.

The estimation values are also shown to the user when the user is going to generate the reports. As this calculation can be costly depending on the number of records and selection the estimation values were also saved in the database and reused. The estimation values are updated only when the number of patients are changed by 10% than the records were at the last time the calculations were made.

The user is blocked from creating strategies without should match and must match fields

The user could have selected any of the combination as the strategy in early versions. But as a basic action to prevent any undesired selection, the user is blocked from creating the strategies that doesn’t have a “Should Match” or “Must Match” field. In other words, the user should have at least selected one “Should Match” field and one “Must Match” field to save the strategy.