I agree with this too and I like the way Dave has expressed this.
@Dave, can you maybe schedule this into a design call and/or summarize
on a wiki page the changes you recommend? I'm also happy to help with this.
Mike
On 01/30/2012 09:46 PM, Darius Jazayeri wrote:
I approve of pulling the rendering mechanism into the core HTML Form
Entry module. I.e. displaying a table of encounters with their obs
exploded according to the underlying form schema.
It still feels like other workflows (e.g. a row-per-encounter register
for multiple patients by location and date, and a HFFS's many
encounters for one patient) belong in their own modules. But if
there's a way to make those modules thinner by pulling useful common
functionality into HFE core, that's cool.
-Darius
On Mon, Jan 30, 2012 at 4:09 PM, Dave Thomas <[email protected]
<mailto:[email protected]>> wrote:
Well, i think the point is that the workflows are very similar,
especially from a technical point of view. You're looking at
renderings of 1-row-per-encounter tables where the columns are
described by the htmlform schema, the obs matching is provided by
the formentrysession, and the things you want to do with these
tables are delete, add or edit a row. The only things that really
differ between the modules (flowsheet vs register vs patient
dashboard) are the encounter list that gets passed to the
renderer, and the 'create patient' capability of the register
module, which is handled by the htmlform tags anyway.
That would be the rationale in merging htmlformflowsheet and the
register module.
The rationale for putting the rendering into htmlformentry is
basically, if we stop thinking about htmlforms as just a form
entry mechanism, and start thinking about them as schema
descriptions of collections of OpenMRS objects in an Encounter, an
object matching engine, and a renderer, then I think it would be
valid to have a renderer for multiple encounters viewed through an
htmlform schema as it is to have a renderer for a single encounter
viewed through an htmlform schema.
The stuff I added to the register module is off-mission from
'register'. But it uses the same jsp and controller -- the
thoughtworks guys did a nice job with the DataTables stuff, so why
do it again somewhere else (for the third time)? I've added a pic.
d
On Mon, Jan 30, 2012 at 2:42 PM, Darius Jazayeri
<[email protected] <mailto:djazayeri%[email protected]>> wrote:
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] <mailto:[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
<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from
OpenMRS Developers' mailing list
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:[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]
