sunsetsystems wrote on Tuesday, April 01, 2014:
I’ve been discussing with a client their need to make some improvements to Layout Based Forms. One of these is a requirement to “share data among multiple forms”. That is, you might have two different encounter forms that can insert or update the same data item. Furthermore this data item might be something like DOB that is already stored somewhere else in the system.
A related thought is that some things that are put into encounter forms are more properly attributes of the visit itself, and are not of some repeatable measurement or procedure. It would be nice to have user-definable visit attributes.
So this brings us to the concept of defining data items and their values separately from layout items. Thus a “data dictionary”.
Here’s a sample table layout that I came up with to support this:
CREATE TABLE `data_dictionary` (
`category_id` varchar(31) NOT NULL DEFAULT '' COMMENT 'Patient, Encounter or a forms.formdir value',
`attribute_id` varchar(31) NOT NULL DEFAULT '' COMMENT 'Identifies the data item within category',
`component_id` int(11) NOT NULL DEFAULT 0 COMMENT 'Usually 0, increments for compound data types',
`data_type` varchar(31) NOT NULL DEFAULT '' COMMENT 'text, longtext, list value, addrbook item, date, datetime, pharmacy, squad, user, billing code, issue, facility',
`list_id` varchar(31) NOT NULL DEFAULT '' COMMENT 'Identifies the list if this is list based',
`max_length` int(11) NOT NULL default 0 COMMENT 'Maximum length of a value',
`options` varchar(31) NOT NULL DEFAULT '' COMMENT 'In case other qualifiers are needed',
`description` varchar(255) NOT NULL DEFAULT '' COMMENT 'Describes what this is for',
-- In the case of a compound data type the following are ignored for all but the first component. --
`multiple` tinyint(1) NOT NULL DEFAULT 0 COMMENT '1 if multiple values/selections are allowed',
`status` tinyint(1) NOT NULL DEFAULT 0 COMMENT '0=system, 1=user, 2=deactivated',
PRIMARY KEY (`category_id`, `attribute_id`, `component_id`)
);
Note that a data item is keyed on a category_id, attribute_id and component_id.
category_id indicates if it’s a patient attribute, encounter attribute or form attribute, and if a form attribute which form. We’ll probably want additional categories.
attribute_id is the name of the data item within its category. An attribute_id that is already a column name in its respective table will have its values stored in that column; otherwise they will be stored in a separate “vertical” table of attribute values similarly to the way the lbf_data table does it. This supports creation of user-defined attributes and has other potential benefits that we can get into later.
component_id exists to support compound data items – items with multiple components, defined with multiple data_dictionary rows, each having the same category_id and attribute_id. For simple data items component_id would always be 0. An example of a compound data item would be the “exam results” data type currently defined for layout based forms.
I can write more, but don’t want to dive into it too deep before getting some initial feedback. Please feel free to comment. Thanks!