Reminder: Create & find trunk-related issues here. Legacy Trac tickets are still available. Problems? Workflow feedback? Need a module project? Open a support ticket.

OpenMRS Trunk

Model must support constraining coded answers to one or more classes

Details

  • Type: Bug Bug
  • Status: In Progress In Progress
  • Priority: Should Should
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: Data Model
  • Description:
    Hide

    Currently, there is no way within the data model to specify the scope of answers for coded concepts like PROBLEM ADDED or X-RAY FINDING.

    Ideally, we should have a mechanism for specifying either 1..n concept_set(s) and/or concept_class(es) that make up the possible answers.

    We could accomplish this several ways:

    • Add concept_answer.concept_class and concept_answer.concept_set to allow class(es) and/or set(s) to be included within an answer set.
    • PRO: smallest change to the data model
    • CON: complicates concept answer code and dictionary UI tools
    • Create concept_coded table (as an extension to concept much like concept_numeric) with concept_coded.answer_filter (varchar) to hold some string representation of classes/sets allowed
    • PRO: answer_filter could be used to restrict answers even as concepts are being defined, the concept_coded would give us a place to define whether answer lists are constraints (must choose from answers) or suggestions (convenient/popular choices, but you're allowed to answer with any concept matching filter)
    • CON: code must be changed to accommodate the new table and handle it along with concept_answer values
    • Add concept.answer_filter (varchar) with a string representation of valid classes/sets
    • PRO: simple data model change
    • CON: puts coded datatype-specific attributes into concept table
    Show
    Currently, there is no way within the data model to specify the scope of answers for coded concepts like PROBLEM ADDED or X-RAY FINDING. Ideally, we should have a mechanism for specifying either 1..n concept_set(s) and/or concept_class(es) that make up the possible answers. We could accomplish this several ways:
    • Add concept_answer.concept_class and concept_answer.concept_set to allow class(es) and/or set(s) to be included within an answer set.
    • PRO: smallest change to the data model
    • CON: complicates concept answer code and dictionary UI tools
    • Create concept_coded table (as an extension to concept much like concept_numeric) with concept_coded.answer_filter (varchar) to hold some string representation of classes/sets allowed
    • PRO: answer_filter could be used to restrict answers even as concepts are being defined, the concept_coded would give us a place to define whether answer lists are constraints (must choose from answers) or suggestions (convenient/popular choices, but you're allowed to answer with any concept matching filter)
    • CON: code must be changed to accommodate the new table and handle it along with concept_answer values
    • Add concept.answer_filter (varchar) with a string representation of valid classes/sets
    • PRO: simple data model change
    • CON: puts coded datatype-specific attributes into concept table

Activity

Hide
Burke Mamlin added a comment - 2009-05-29 16:41:13 EDT - edited

A variation of the first solution would be to use two new tables for answers that are sets or classes:

  • concept_answer_set
    • concept_answer_set_id
    • concept_id
    • set_id
    • <create and retire attributes>
  • concept_answer_class
    • concept_answer_class_id
    • concept_id
    • class_id
    • <create and retire attributes>

PRO: more normalized design, existing concept_answer (and related code) unaffected, distinguishes between a "choice list" and whether or not classes and/or sets are viable answers as well
CON: two new tables for data model

Show
Burke Mamlin added a comment - 2009-05-29 16:41:13 EDT - edited A variation of the first solution would be to use two new tables for answers that are sets or classes:
  • concept_answer_set
    • concept_answer_set_id
    • concept_id
    • set_id
    • <create and retire attributes>
  • concept_answer_class
    • concept_answer_class_id
    • concept_id
    • class_id
    • <create and retire attributes>
PRO: more normalized design, existing concept_answer (and related code) unaffected, distinguishes between a "choice list" and whether or not classes and/or sets are viable answers as well CON: two new tables for data model

People

Dates

  • Created:
    2006-04-07 19:51:05 EDT
    Updated:
    2010-08-12 10:15:33 EDT