Consider the dilemma of change or not change software and the question attached to it: convert the data or leave it behind. There is no doubt the data is valuable, you have paid a bunch of money to get it. It is also clear what the condition of the data appears to be in your current system. The question then is when you remove it from that system how much of it will correlate in your new system? The answer will be a bit different depending on three factors.

  • The data integrity requirements of the new system
  • The hidden quality and integrity of your data in your old system
  • The skill and interest level of your conversion team

Data Integrity
Each system has data integrity requirements that are built in by the database structure. Some of these can not be compromised by the application code such as a duplicate patient ID. If that patient ID is a KEY in the data base, it can not be duplicated. The database engine will not allow it. However, if it is not a database KEY then duplicate patient IDs can get into the system whether allowed by the application or not. We see it all the time and clients are usually surprised to see duplicates which their software does not allow. However, when they see specific patient records and their relative patient IDs it is no longer a mystery. Often we hear a comment like “oh yes, I know where those came from. We used those numbers to identify …”.

This becomes important when choosing a new system. The people who provide the demonstration of its capabilities most likely do not know the restrictions or lack of them in the database design. They do know what the application requires and as the example noted above demonstrates, that is not necessarily what you get.

Your old system
This same dialogue applies to your old software but usually to a higher degree of dysfunction. It is older software, built when data integrity rules in the industry were something less stringent. The database engines at the time they were designed may not have provided for as much integrity as was needed so it was programmed into the application. This did not always produce satisfactory results. These conditions allow for a higher level of uncoordinated data, lack of integrity in older systems than what is often found in newer systems.

The data conversion team:
Data conversion technicians are no different in the variation of their skill levels than any other group of professionals. For example, you probably know a plumber or attorney who work you do not like. The same goes for conversion technicians. There are some who will be careful and detailed and thorough, and others who will not. A statement like “your old data does not support what you want done” may be true. It may also be translated as “I can not make your data work”. Or “I can not work any longer on your conversion because the money you paid for it has run out”.

A closing thought
It is also worth while to ask about the credentials of the people who designed the system. A database expert (not a programmer) and a user expert (not a front office clerk) are the minimum essentials for the design team. If the question is not answered in any meaningful way you would do well to be suspect. Internal system integrity is as important as features and functions.

Changing software does not have to be a nightmare. The costs can be managed to be reasonable. Data conversions can provide good, useful results. Ask questions. Compare the answers across the board. Do not make an emotional decision, that will be bad for your practice and your pocketbook.