Hi Dave, What would be the benefit of merging them? I'm having trouble thinking of a use case where having genericized rendering modes would help. (I'm sure there's one I'm not thinking of though...)
There's definitely symmetry between HFFS rending multiple encounters for one patient in a single view, whereas Register renders encounters for multiple patients. But the workflows seem quite different. -Darius On Mon, Jan 30, 2012 at 1:46 PM, Dave Thomas <[email protected]> wrote: > Hey everyone. There are currently two htmlformentry add-on modules, > register and htmlformflowsheet. These two modules essentially provide > custom rendering of htmlforms for different circumstances -- register as a > way to model paper registers using an htmlformentry schema (and i recently > added the capability of using the register renderer to add htmlform-based > tabs to the patient dashboard). And htmlformflowsheet for doing embedded > htmlforms within htmlforms, and for building custom, easy-to-configure > tabbed interfaces containing htmlforms. > > Register module has outgrown the name 'register', and at their core, > htmlformflowsheet and register are basically just htmlform renderers for > multiple encounters based on htmlform schemas. > > How would people feel about 1) merging these modules into a > 'htmlformextension' (or similarly named module). Then we'd have a module > that provided a couple of different renderer types for looking at data > entered through htmlforms. And/or, keep these modules separate but merge > renderers themselves into htmlformentry, to expose these for other modules? > > Any thoughts about where we want to go with this, if anywhere? > > Also, does anyone have any other general ideas around more ways in which > to build htmlform-driven interfaces? Design ideas, etc... that could > inform this discussion? > > Our needs at PIH rwanda in terms of workflows for getting data into the > database have grown beyond the usual openmrs formentry model -- we've > headed down the htmlform-based-interfaces road because we've got clinical > charts, patient flowsheets, and MoH-issued registers that don't fit the one > form per encounter model. And, we've taken our lumps in terms of trying to > report on data entered through custom modules (i.e., schema-less > encounters), and I'm of the opinion that NO observational data should ever > be entered into openmrs without having some mechanism for saving the schema > associated with that data. Hence the push into htmlformentry driven > interfaces. > > d > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
