Re: CONTENT MANAGEMENT vs DATA MANAGEMENT, my main point is that "Manage Encounter Types" and "Manage Encounters" should go in different places. The former is about managing metadata or system configuration. The latter is DATA MANAGEMENT.
(So, yes, managing the definitions of Person Attribute Types should * definitely* go in a different section from managing Persons.) -Darius On Sun, Oct 2, 2011 at 7:13 PM, Burke Mamlin <[email protected]>wrote: > On Sun, Oct 2, 2011 at 7:57 PM, Darius Jazayeri > <[email protected]>wrote: > >> Hi Vlad, >> >> A few comments: >> >> 1. I would want another high-level category for DATA MANAGEMENT. (This >> would include managing Patient, Person, Encounter, Observation, and Order.) >> Fixing data entry errors is distinct from configuring the lists of >> locations, encounter types, etc. And I think I'd want a high-level category >> for ANALYSIS & REPORTING. >> > > I thought CONTENT MANAGEMENT was data management. Do we really need to > split up managing persons & managing person attributes into separate > sections? > > >> 2. I don't love the distinction between CONTENT MANAGER and CONCEPT >> MANAGER. Maybe just changing a name would fix it, but it doesn't feel quite >> natural for me to have Forms go under CONCEPT rather than CONTENT. Maybe >> rename it to CONCEPTS & FORMS. :-) >> > > How about SYSTEM ADMIN → ADMINISTRATION and CONCEPT MANAGEMENT → > CONFIGURATION? > > >> 3. Add-on modules should not all go in their own special place. Rather >> they should be encourages to plug into the relevant high-level categories. >> E.g. all get grouped in a special place. The right approach is that modules >> should be able to plug into the relevant high-level categories. (For example >> a module might plug into both CONTENT MANAGEMENT *and* DATA MANAGEMENT.) >> Obviously most modules won't naturally do this out of the box. We'll need to >> tell them how to do so. >> > > Agreed, but we will still want a "Modules" entry in the ADMINISTRATION > section under which to enable, disable, install, and remove modules. > > -Burke > > >> >> -Darius >> >> On Sun, Oct 2, 2011 at 1:07 PM, Vlad Vega <[email protected]> wrote: >> >>> Hi All, >>> >>> I've been slowely developing a menu system and wanted to come to some >>> initial conclusions in the what goes where problem. >>> >>> Please take a look and see if you believe these assignments fit. >>> >>> Key: >>> ALL CAPS: Super Category >>> Under small caps: Sub categories of links and modules. >>> >>> SYSTEM ADMIN >>> Users >>> HL7 Messages >>> Maintenance >>> Modules >>> Logic Module >>> MRN Generator >>> HTML Form Entry >>> Reports >>> Analysis and Reporting >>> >>> CONCEPT MANAGER >>> Programs >>> Concepts >>> Forms >>> Xforms >>> Report Definitions >>> >>> CONTENT MANAGER >>> Patients >>> Persons >>> Encounters >>> Locations >>> Observations >>> Orders >>> Scheduler >>> From Entry >>> >>> Also, I would like to put any module that the user downloads into a >>> system >>> admin - designated Subcategory (so that those modules will show up in a >>> separate grouping under a subcategory in addition to the links.) >>> >>> Vlad >>> >>> _________________________________________ >>> >>> To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail to >>> [email protected] with "SIGNOFF openmrs-implement-l" in the >>> body (not the subject) of your e-mail. >>> >>> [mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l] >>> >> >> ------------------------------ >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-implement-l>from >> OpenMRS Implementers' mailing list > > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-implement-l>from > OpenMRS Implementers' mailing list _________________________________________ To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-implement-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l]
