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 _________________________________________ 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]
