* Configuring Patient Merge

The default behavior of the Patient Merge function is basically to recursively walk the "record tree" of the "source" patient, and copy records to the "destination" patient. The type of relations has be to considered:

• Records in 1:N relations are copied.

• For 1:1 relations it is important NOT to create more than 1 (active) record in the relation in destination patient:

  • When then destination patient does NOT already have an (active) record in the relation, the record is copied from the source patient.

  • When the destination patient already HAS an (active) record in the relation, a conflict arises. The user interface has the following options for handling this type of conflicts:

    • The record from the "source" / "donor" is copied to the "destination" / "survivor".

    • The record in "destination" / "survivor" is left unchanged.

    • The "newest" record will "survive" - e.g. , but if the "source" record is newest, the record in the "destination" patient is recplaced with a coyp of the record in the "source patient.

      • If the record in "destination" / "survivor" is newest, the record is left unchanged.

      • If the record in the "source" patient is newest, the record in the "destination" patient is replaced with a copy of the record in the "source" patient.

      In current version this is the only selectable option in the user interface.

      Checking which record is "newest" involves comparing date/time values. Per default the DATE_START field is used - other fields may be specified by configuration.

Why is this configuration possibility needed?

• Sometimes TOPICA applications are constructed to keep copies of data in some external system. For example in healthcare record system, it is very common to use encounters. When a TOPICA application is integrated with such a system, data in the TOPICA application's database should be synchronized with the encounters in the external healthcare record system. This synchonization may be implemented by for example custom websevices.

• To make such a syncronization work, it is necessary (in the TOPICA application) to configure a key field in the form template. This key field is used to hold the external encounter number..

• In the TOPICA application it is imperative, that these key values (e.g. encounter ids) are unique per patient.

• Because "patient merge" might be executed several times (and/or because of the way synchronization of e.g. encounters is implemented), it is quite possible, that the "destination" patient already contains an encounter having the SAME key value as an encounter on the "source" patient. In this case, the "patient merge" operation must NOT create a new encounter in the "destination" patient. in stead, all subrecords created "below" the encounter in the "source" patient should be "merged" into the existing encounter on the "destination" patient.

• To ensure this, the configurator must specify the name of the key field used for merging.

This configuration is done per table (in the dynamic part of the data model), so this is specified in the structure file.

Each StructureElement has a property MergeByFieldName.

• When MergeByFieldName is blank (the default situation), records in 1:N relations are copied from "source" patient to "destination" patient.

• When MergeByFieldName is NOT blank, the contents is interpreted as field name (in the current table).

  If the specifed field exists, the value of that field in the record in the "source" patient is the key (=key to record e.g. encounter ia an external system). TOPICA searches for a record in the "destination" patient having the key value.

  • If such a record is found in the "destination" patient, no new record is created in the "destination" patient. Any child records of the record in the "source" patient are merged into the existing record in the "destination" patient.

  • If such a record is NOT found in the "destination" patient, the record in the "source" patient is copied into the "destination" patient. Any child records of the record in the "source" patient are merged into the newly created record in the "destination" patient.

Why is this configuration possibility needed?

• Normally when looking for a record by a given key (because MergeByFieldName is set, i.e. not blank), the system searches within the current "parent record".

• In some situations it is possible that a record with the given key value exists under some other "parent record". Example:

  Copy

  Source
      PeriodOfCare Key="P01"
          Encounter Key="E01"
      PeriodOfCare Key="P02"
          Encounter Key="E02"
  Destination
      PeriodOfCare Key="P01"
          Encounter Key="E01"
          Encounter Key="E02"
      PeriodOfCare Key="P02"

  In the default mode, the "patient merge" function will search for an Encounter with Key="E02" under PeriodOfCare with Key="P02" and NOT find any. Switch to search on patient level WILL find one record.

This configuration is done per table (in the dynamic part of the data model), so this is specified in the structure file.

Each StructureElement has a property MergePatientLevel.

• When MergePatientLevel is not defined (the default situation) or equal to false, search is restricted to current parent record.

• When MergePatientLevel is equal to true, search is "broadened" to patient level (i.e. all records of specified type on patient are searched).

Why is this configuration possibility needed?

• As described above, the system sometimes need to determin wihch record i "newest".

This configuration is done per table (in the dynamic part of the data model), so this is specified in the structure file.

Each StructureElement has a property MergeNewestFieldName.

• When MergeNewestFieldName is blank (the default situation), the DATE_START field is used to determine which record is newest.

• When MergeNewestFieldName is NOT blank, the contents is supposed to be a field name (in the current table). This field is then used to determine which record is newest

Why is this configuration possibility needed?

• Sometimes form templates are constructed to hold copies of patient properties (national id, name, address, etc.).

• This might seem to be superfluous, redundant information - but it is necessary to keep the values at the time the data was entered, in case the patient changes name or address after the record is saved.

• After a "patient merge" operation, you would want that such fields will contain values from the patient the copied record belongs to (the "destination" patient) - NOT values from the patient the record was copied from (the "source" patient, which is the default, because all field values are simply copied).

• To ensure this, the configurator must specify how the value is to be set in the copied records.

This is done per field - so this is done in the form templates.

All template items, that generate fields in the database (= those items that have the DataName property), have a SetValueOnCopy property. See DataNameBase Reference.

• When SetValueOnCopy is blank (the default situation), the field values is copied unchanged.

• When SetValueOnCopy is NOT blank, the contents is interpreted as a TOPICA Basic expression. This expression is evaluated, and the evaluated value is set on the newly copied record.

The demo application DemoPatientMerge demonstrates some of the features described in this page.

DemoPatientMerge does not have interfaces to external systems to keep data synchronized. In stead, it is possible for the end user to edit values in the Key field. In "real world" scenarios such key fields should be read only or hidden.