The first issue is to decide which dataset will be “B”, and which will be “A”. Simply selecting the set which has more accounts to be “A” (permanent) is probably not the most important criterion. Rather, the most important criterion is that “A” should be the dataset whose data is to take priority in the event of a conflict. Whenever a conflict exists, the dataset designated as “A” will always take priority in the merge. With the dsSync option, the remote site will usually take precedence, since it is “updating” the main site.

Procedure codes and diagnoses use standard coding, so unless the practice used internal codes, these should be compatible. It must be decided whether to add codes from B to A which are not already in A. If a transaction-level merge is being performed, this will be necessary at least for codes that exist in transaction of B that are not in the A support files. For added codes, the B fee schedules will be maintained. Otherwise, the A schedules remain as-is. Note that there may be undesirable results in the added procedure codes. For example, if Fee Schedule #3 is Blue Cross and #4 is Workers Comp in A, but they are the reverse in B, they will be brought over as-is by the merge, requiring the practice to manually reverse them, and any other fee-schedules/profiles. Diagnoses are quite simple, so there will be no manual issues to resolve.

Insurance Plans, Referring Doctors, Facilities and Doctors are all “numbered” support files. Therefore, unless they were entered in both datasets with the same numbers, they will be different in each dataset. For instance, plan #5 may be blue cross in A, but workers comp in B. The A set will become the default. However, the B codes must still be addressed insofar as they may be referenced in the conversion. For instance, if a patient in B has a referring doctor #7, the merge will need to know what referring doctor # to use when the patient is added to A. The same applies to insurance plans (if policies are being merged along with demographics), to Doctors (because doctors are referenced in the doctor-of-record of the patient) and to Facilities (if transactions are being merged, since facilities are referenced in the ailments). The referring doctor mentioned above is referenced in the patient record and in any ailments.

To enable the merging of these support files, translation tables should be made. In the remote column, the B code is placed. In the local column, the desired A code to be used is placed. If a B code does not already exist in the A dataset, do not map it; it will then be created as a new record.

From a practical standpoint, several things should be kept in mind. The Doctor table is the most crucial, and should be prepared carefully. In most cases, no doctors from A will exist in B. An empty map table could be created (saving time), but then the conversion would create the doctors from B in the A dataset in a haphazard manner. The practice may prefer to manually add the doctors to A and create a mapping table, to ensure they are assigned desirable numbers and sequence.

For the referring doctor “map”, a merge option exists to automatically match by UPIN. If this option is used, no map table is needed. Any doctor in B that cannot be matched in A by UPIN will be added to A.

For the insurance plan “map”, the practice may wish to map the most common plans. But the remainder could be left unmapped. The unmapped plans will be brought across and will undoubtedly result in many duplicates, but this may be more practical than trying to map 1000-plus plans manually. Also, a utility exists to merge plans after-the-fact (although that merge can be time-consuming). It is recommended that the practice map as many as possible to avoid headaches later.

For the facility map, the practice may allow the merge to create facilities automatically (by not creating a map), or create facilities and map them manually. Since there are usually not many facilities, this will not take long if the practice wishes to control the sequence in the final dataset for the new facilities. Also, there will probably be duplicate facilities, so a mapping is preferable.

If appointments are being merged, mapping tables will be needed for appointment reasons and room numbers.

If clinical history is being merged, a mapping table of clinical types will be needed. This is necessary to prevent a conflict in case both datasets use the same clinical types for different purposes. The merge will automatically create codes in A which do not already exists.

If transactions are being merged, adjustment #s should be mapped. Charge Locations, Posting Locations and Departments may also need to be mapped if used.

Several fields may be used differently from A to B. These should be analyzed so that they can be handled by the merge. Mapping is available for any field, but in some cases customizing the merge may be needed. When no easy mapping solution exists, the merge can “clear” the value, or assign a default value.

The fields to consider are: status, billtype, and class. Also, all extended information fields should be considered to ensure they are used for the same purpose from one dataset to the other. Similarly, the ailment screens need to be analyzed for compatibility in usage of the fields.

Other files which may need to be resolved include office notes, appointments and clinical history. For office notes, there is no problem as long as the notes category names do not conflict. For clinical history, there will be a problem if the same clinical type was used by both A and B for different sets of codes. For appointments, a map of reason codes and rooms may need to be created. If non-compatible slot-lengths were used (i.e. 10 minutes in A, 15 minutes in B) a merge cannot be performed. Similarly, if complex templating was used by one or both of the datasets, merging appointments may be difficult or completely impractical.

The following fields may be used to determine a “match” between patient accounts: last name, first name, middle initial, social security number, birth date, home phone, address, city, state and zip. Any combination of these may be designated the primary match criteria. For the primary criteria, if all selected fields match, and only one match exists in A, it is used. If no patients exist in A where all the specified fields match, the patient is added. In addition, tie-breaker fields can be used for a situation where more than one match exists in A based on the primary criteria. With the tie-breaker fields, you specify which fields to use, and how many should match (i.e. use city, state and zip as the tie-breaker fields, and accept 3 of 5 as the match. If there is only one match, it is used. If there is more than one, the merge will flag the account. The reason it is important to match to the exact account is that certain information may be added from the B account to the A account by the merge.

For the simplest “matching” conversion, if a match exists, no further information is brought across. However, the practice may wish to bring across comments, extended information, office notes, insurance plans, appointments and clinical history from B to add to the A account. In this case, the merge will skip information from B which would conflict with A. For example, if A already had patient comments, then the comments from B will be skipped. If A already had extended info, the extended info from B will be skipped. Policies are not brought across from B to A for matched accounts, since the policies are likely to conflict, and there would be no way to automatically resolve the priority list.

When using dsSync in a two-way update scenario, complications may result from updating the same record at both the remote site and the main site (i.e. the main site edits a charge to update the CPT© code, and the remote site edits a charge to correct the insurance). DsSync will use precedence rules to determine which changes are reflected. However, for true data integrity, processes should be implemented to prevent such possibilities (i.e. if the remote site performs initial charge entry, and the main site performs all billing and payment posting, the remote site should be precluded from editing the charge after it is uploaded to the main site, thereby preventing any conflict. The same would be true for demographics.

Currently, the merge will not handle “optional” files, such as collection module information, managed care information, prescriptions, lab, quality care, etc. If such information exists for a patient in B, it will not be copied to A when the patient is merged into A.