A concept datatype prescribes the structured format by which you desire the data to be represented. In simple terms, the datatype defines the type of data that the concept is intended to collect.
OpenMRS Concept Datatypes
Numeric
Any data represented numerically. There is an option to provide ranges for the numerical values, if this is appropriate. As of OpenMRS 1.9, data entry on htmlforms and Infopath forms are limited by the absolute minimum and maximum values. In the example of Serum Sodium, the absolute range of 0 (min) and 2000 (max) will prevent data entry of any value outside this range. There are no value checks for normal or critical ranges, but it is still advisable to add those values. They could be used to generate reports which should entry of values outside these ranges.
The units (e.g. weight in kg and height in cm) could be included for the numerical values.
|
 |
Coded
Allows answers to be only those provided, e.g. Blood type can only be A+, A-, B+, B-, AB+, AB-, O+, O-
Text
Open ended text responses
N/A
The standard datatype for any non-query-like concepts, e.g. symptoms, diagnoses, findings, anatomy, misc, etc. Any concept which does not itself collect data.
Document
Date
Structured day, month, and year
Time
Structured time response
DateTime
Structured response including both the date and the time
Boolean
checkbox response, e.g. yes or no queries (starting from OpenMRS v1.7, you can modify existing concept with boolean datatype to coded answers).
Best-practice for implementing OpenMRS is to never use the Boolean datatype. Any time you are thinking of creating a Boolean concept, you should create a Coded one instead, with "Yes" and "No" as answers.
Boolean answers (simple "Yes" or "No") are very often insufficient. In most cases, you also want to be able to record at least one other option ("Unknown") to distinguish between "left unchecked on purpose" and "not addressed." As an example of the importance of handling missing information properly, HL7 defines 9 different flavors of missing information. By creating your concept with the Coded datatype in the first place, it will be trivial for you to add other possible answers later, if (when) someone asks you to. |
Rule
Structured Numeric
Complex numeric values possible (ie, <5, 1-10, etc.) This has not been implemented yet.
Helpful Notes
- All concepts can be used as answers to question concepts, regardless of their datatype. This includes other question concepts.
- For example, Civil Status is a question concept to ask the marital/civil status of the patient. However, another question may use Civil Status as one of its possible coded answers.
- To reiterate: any kind of concept can be used as an answer to a coded question concept.
- A concept's datatype should not be changed once it has been used to stored data.
- If a concept is defined with any datatype that stores data (such as numeric, coded, text), and data has been collected using that concept, do not change its datatype.
- For example, you may have a concept with class= Question and datatype= Coded. After months of collecting this data, you may decide that it would be preferable to collect numeric data for this question. Do not change the datatype of the existing concept to become class= Question and datatype= Numeric. Changing the datatype of a concept that has already been used to store data will seriously harm the database by indicating that conflicting information types will be collected using the same concept. In this case, you should create a new concept with a Numeric datatype.
- If a concept is defined as a datatype that does not store data (such as N/A), it may be changed to become a concept that stores data. For example, you can changing a concept with class= Finding and datatype= N/A to become a concept with class= Finding and datatype= coded. However, this should be done with much caution.