I am a Business Analyst on the Bahmni team. Recently we encountered a need to have different sections on our registration page. More specifically, the client for whom we are implementing Bahmni would like to have a top section that records core person attributes followed by one or more sections that record the patient attributes.
For this we believe the best way to go forward would be to group the patient attributes and then show each group as a different section on the registration page.
Hence, we wanted to ask if there is a way to achieve this grouping.
For this requirement, can we introduce a person_attribute_type_group table to be able to group attributes? or a group_name column on the person_attribute_type table?
There are two sets of address details that need to be recorded, one would be the patient’s address which would be recorded in the address hierarchy that OpenMRS provides, the other is the address of the facility where the patient is being treated along with some additional contact details of this facility. This would be followed by a set of patient attributes that would record some dates for the patients’ enrolments into some medical programs. There is a need to have them in separate sections because we are trying to establish coherence with paper forms that would be filled by the patient. (The data would then be entered into the system by data entry personnel, thus if we have these groupings it would make the data entry much more logical)
Please let me know if any other information is needed from our side.
Attribute tables (location_attribute, person_attribute, provider_attribute, visit_attribute) exist to allow implementations to extentd – i.e., add “virtual columns” to the core tables (location, person, provider, visit). Attributes that are commonly used by implementations are candidates to become columns in the core model. Creating groupings of attributes feels unnatural, since it is like asking to group columns in a table.
It sounds like you’re wanting to store the semantic relationship between virtual columns (i.e., all the facility location attributes belong together). If you were adding these as columns to the person table, that relationship (the fact that certain columns belong together) would either be hardcoded into your forms or you would change your columns (e.g., store facility address information as a delimited string in a single column).
I agree with Burke that it feels wrong to introduce Grouping into the
domain model for PersonAttributeType (presumably you’d also want Sorting to
go with that, etc).
As Burke suggest, you should think of this as a UI/layout configuration on
top of the underlying domain model, rather than adding direct support for
this in the domain model.
Also, if you’re talking about configuring the layout/grouping of addresses,
program details, and person attributes, it feels like you want some sort of
layout that covers all these things, not just grouping/sorting within a
single data type.