| Table of Contents |
|---|
Concept creation
Avoid Duplicates! Avoid Duplicates!
When creating a new concept, use the "similar concepts" resources and/or search your dictionary carefully to be certain that there is not already a concept that meets your needs.
- Create synonyms (alternative, valid names) for your concepts. This helps people find the concept and will help you avoid creating duplicates.
Concept Naming
- Only use alphanumeric characters (letters and numbers) and simple punctuation sparingly – e.g., comma (","), parentheses ("(" and ")"), and forward slash ("/").
- Descriptions may contain non-alphanumeric characters
- Sentence-casing is recommended – i.e., either all lowercase or uppercase first letter.
- Avoid using all uppercase
- For drug names, some people use Tall Man Lettering to uppercase certain parts of drug names that are confused by providers, since this has been proven to reduce medication errors.
- Be consistent!
- Consistency in naming helps users predict concept names and makes the dictionary much easier to manage.
Design for Re-use
Well-designed concepts can be used in several different contexts (e.g., multiple, different forms).
- Avoid making your symptoms & diagnoses concepts boolean; rather, use datatype N/A for these and use them as answers (not questions). This promotes re-use of these concepts.
- POOR DESIGN: a boolean "HIV" concept answered yes/no based on whether or not the patient has HIV.
- GOOD DESIGN: a coded "DIAGNOSES" or "PROBLEM ADDED" concept that is answered with the concept HIV (the HIV concept has datatype N/A).
Concept naming
- Always work with your end users to ensure the your concept names make sense to them and match their workflows.
Modeling diagnoses
Here are some notes/conversations related to concept modeling that may be helpful resources when confronting modeling issues.
...
If someone wants multiple choice answers for 1..n diagnois, then you are collecting two observations in each case: a multiple choice answer and the diagnosis for which the answer applies. There are a several ways to skin this.
Flat by diagnosis (add coded answers for each diagnosis)
| Panel |
|---|
MALARIA with coded answers TRUE, FALSE, UNKNOWN, NO DATA AVAILABLE |
...
CON
not scalable, ties you to one model of answers to diagnoses and these must be replicated/managed for every diagnosis in the system.
Fully abstract (one concept for diagnsosis and a 2nd for answer to multiple choice question)
| Panel |
|---|
INQUIRED DIAGNOSIS as coded answered by diagnosis |
...
CON
needs tools/knowledge to convert back to one complex data point, diagnoses stored in a questionnaire-specific manner
Abstract, but use existing DIAGNOSIS concept
| Panel |
|---|
INQUIRED DIAGNOSIS as coded answered by diagnosis Store TRUE answers as DIAGNOSIS with coded answer MALARIA, ASTHMA, etc |
...
CON
application must know to treat TRUE answers differently
Flat by answer (one concept per answer for questionnaire)
| Panel |
|---|
DIAGNOSIS CAROLE1 QUESTIONNAIRE DIAGNOSES OPTIONS as a concept_set of the above concepts |
...
CON
requires search for multiple concepts (could be facilitated by concept_set)
Additional information
- The MVP-CIEL concept dictionary is a valuable resource (either as a starting dictionary or to look for best practices)
- Notes or recording from the 2012-Sep-12 OpenMRS University forum, where concept management experts discussed best practices.