concept_id (id of question concept, numeric question)
concept_id (id of question concept, coded question)
- currently has logic issues regarding coded answers
concept_id (id of question concept, freetext question)
value_coded (id of coded answer)
obs for Loser concept_id are retired (with note), and then new obs are generated with Winner concept_id

concept_id
- while the Merge Concept preview page displays the references to the to-be-merged concepts in the drug table, the table is not impacted after the merge is complete

route
- the Merge Concept preview page does not display the references to the to-be-merged concept in the drug table, and the table is not impacted after the merge is complete

dosage_form
- the Merge Concept preview page does not display the references to the to-be-merged concept in the drug table, and the table is not impacted after the merge is complete

Output to notify user of places where the drug table was impacted, so that the user can then double check to ensure subsequent drug formularies don’t exist and, if they do, resolve them manually. Perhaps future iterations of MCM can take the next step of resolving any existing or created (through the merge) duplicate drug formularies. **functionality not yet available**

**functionality not yet available**

concept_id (for all entries with a field_type=1 (concept))
fields with Loser concept_id are updated to now have the Winner concept_id
name
description
- the Merge Concept preview page correctly displays the form with references to the to-be-merged concepts in the Field table, and the concept_id column is properly updated with the Winner concept. However, even though the Loser concept_id was updated, it seems that the "name" and "description" columns from the Loser concept also need to be updated with the Winner concept's information. Otherwise, those fields will still contain metadata from the Loser concept in the Field table. (8/16/13)

Program

concept_id
programs with Loser concept_id are updated to now have the Winner concept_id
name
description
- the Merge Concept preview page correctly displays the form with references to the to-be-merged concepts in the Program table, and the concept_id column is properly updated with the Winner concept. However, even though the Loser concept_id was updated, it seems that the "name" and "description" columns from the Loser concept also need to be updated with the Winner concept's information. Otherwise, those fields will still contain metadata from the Loser concept in the Field table. (8/16/13)

concept_id
program workflows with Loser concept_id are updated to now have the Winner concept_id
- the Merge Concept preview page does not currently display concept references in the Program_workflow table

concept_id
program workflow states with Loser concept_id are updated to now have the Winner concept_id
- the Merge Concept preview page does not currently display concept references in the Program_workflow_state table

foreign_key (if format = concept)
person attribute types with Loser concept_id are updated to now have the Winner concept_id

concept_id (id of question concept)
- cannot currently be tested due to incorrect logic issues for merging coded questions
answer_concept (id of the answer concept)
- the Merge Concept page does not display accurate information regarding Concept Answers
duplicate concept_answer (uniquely identified via concept_answer_id) will be deleted, kept track of in a log, so long as all of the old data is also updated so that later updating an old encounter wouldn't fail validation **functionality not yet available**

concept_id
- while the concepts are accurately merged, the concept_name table is not updated. it seems that either the names associated with the Loser concept should be voided, or they should be updated with the concept_id of the Winner concept. The same logic could apply to concept synonyms, which are also stored in the name column of the concept_name table.

concept_id (id of set member)
- concept_id (the set member) is correctly updated. however, after the concepts are merged, there are more than one concept_set_ids tied to the same concept_id for a concept_set. in other words, the Loser concept_id was updated to the Winner concept_id, so now we have two concept_set_ids for the same concept_id for a given concept set. not necessarily problematic, but worth pointing out.
concept_set (id of concept set parent)
all set member concept_ids are moved from the Loser concept set to the Winner concept set.

**functionality not yet available**

Potential duplicates created, as a result of the merge: Drugs, Programs, Orders, Concept Sets, Person Attribute Types
Text references: HTML Forms, Global Properties, etc.
Event published that other modules can subscribe to (if they use concepts in their tables) and handle accordingly