Testing Merge Concept Module

Owned by Lauren Stanisic
Last updated: Mar 28, 2014 by Ozge CatalbasVersion comment
4 min read

Sample Table

  • Field 
  • Field 
  • Field (as many fields listed as are applicable)
  • Note (if applicable) 

Obs

  • 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

Drug

  • 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** 

Drug_ingredient

**functionality not yet available** 

  • concept_id (id of an ingredient concept)
  • unit

Orders

  • concept_id
  • orders with Loser concept_id are updated to now have the Winner concept_id

Field

  • 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)

Program_workflow

  • 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

Program_workflow_state

  • 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

Person_attribute_type

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

Concept

  • entry for Winner concept is kept active, entry for Loser concept is retired

Concept_answer

  • 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_name

  • 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_set

  • 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.

Concept_numeric

  • concept_id **functionality not yet available** 

Concept_complex

  • concept_id **functionality not yet available**  

Logs/Output for the user

**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

Other

  • Optimizing merges to handle a very large load of data  

Not included

  • drug formularies (drug_id), and references to drug formularies