dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

Greetings

Back in the land of the little people and the bogs.  I've just
returned from a week in Rwanda (which was much too short) where I had
the opportunity to work with Arthur Heywood and some good people in
the Rwanda MOH who have done a great job at redesigning the MOH
collection instruments ie. the forms.

Most of my week was spent on infrastructure stuff but towards the end
of the week I had a (first) opportunity for me to work on the frontend
of the dhis process.  This was a *really* worthwhile process for me
and I learned a great deal.  Anyway, in the process of helping the
implementors move from the form design to coding the dhis dataelements
I am left with two interesting implementor design issues which I would
appreciate some input on.

The first relates to the attached picture file
(split_dataelement.png).  A naive implementation of this form section,
which I suspect might also be the most common, is to make the contents
of the Diagnosis column (Mental Problems, Epilepsy, Diabetes etc) as
the datelements.  And to create two categories (a Sex/Gender category
and another category for new cases, old cases, referrals and deaths).
The temptation to do this is of course very strong, because we can
then use the automatic form layout facility to present an html form
which looks like the paper form.  But to me at least, this seems
clearly wrong ... in fact something of an evil.

New and old cases have nothing to do with referrals and deaths (apples
and oranges).  What is actually underlying a more nuanced reading of
this form are two datelements for each of the diagnosis column eg.
Epilepsy Cases and Epilepsy Outcomes.  I've tried to illustrate this
by boxing them off in the table.  If I am reading this right then the
use of auto form layout is positively driving the implementor to
create both wrong dataelements and wrong categories.

In fact a deeper look at this (since drawing the picture) seems to
indicate that a better dataelement breakdown might even be "Chronic
Disease and Mental Health Cases" and "Chronic Disease and Mental
Health Outcomes" for which we have an additional category (dimension)
for the diagnosis which would be a subset of a list of ICD10 codes and
descriptions.  This breakdown has the combined effects of reducing the
dataelement count as well as incorporating ICD codelists which could
be useful for cross-matching against other data later.

So as a consequence of this little bit of analysis, I have recommended
to the implementors that they *really*, *really*, *really* should
avoid auto-form layout completely as following the logic of form
layout necessarily leads them to the evil of poorly constructed
structural metadata.  The issue is illustrated in the attachment, but
this pattern repeats itself on various parts of the form.  But I am
surely not the only one to have observed the anti-pattern of
structuring dataelements and categories on the basis of what we want
the dataentry form to look like.  I would welcome some feedback from
others on this before I lead them down this road.  Do we have any good
experience from the field elsewhere on this subtle process of teasing
out the actual dataelements and dimensions from their visual
representation on forms?   From the many databases I have looked at,
we certainly do have many examples of the naive, crude approach.

For the moment the implementors are prepared to put in the effort of
doing custom form design.  My suggestion has been to put the form
layout on the back burner initially - this week - and focus on
identifying correct, or at least sensible, dataelements and
categories.   As a carrot, I have promised to provide some simple
tooling to help make the generation of html tables and mapped cells a
bit easier.  In the short term this won't be in dhis as we are too
close to release.  I'm not even too sure how I'm going to do this yet,
but I am prepared to do anything to prevent then doing the
datastructuring wrong.

Right.  That was conundruum number one.  Conundrum number two is not
entirely unrelated ....

We are all familiar with our current problem of agegroups, or more
generally the issue of unique category option codes.  There are the
usual categories like {"<5",">=5"} and {"under5","5-18",">=19"} etc.
We have a longer term plan for tying these up with concepts but that
is not targeted at the upcoming release.  But after 15 cups of coffee
on Saturday afternoon it occurred to me we could have a reasonable
workaround.  It seems there is nothing to prevent the implementors
having a single age group category containing *all* the age groups.
The main thing one loses by doing this is that is the auto-form layout
would be a mess (theoretically they can grey out the unused options
but that would lead to more grey than white on the form).  But in
light of the discussion above regarding identifying dataelements and
dimensions, we have decided to avoid the evil of the auto form layout
anyway.  In which case, the implementor can, indeed he must, select
the categoryoptioncombos to use individually anyway.  So he can
constrain the agegroups to collect against in his design of the custom
html form layout which seems adequate to me.

So a question:  are there any unforeseen consequences I might have
missed in creating a single age group category and using it like this?
 I can't off hand think of any which are too serious, but I could be
wrong.

Final note - a strong motivation for trying to get this structural
metadata sensible is that in Rwanda, at least in the medium term,
dhis2 is likely to be acting as the authoritative health information
metadata repository for the country.  This means that other 3rd party
systems will be obliged to use metadata codelists provided by dhis to
mediate exchange between quite a heterogenous mix of systems.  Given
this requirement we have to somehow avoid inscribing the two dhis
idiosyncracies described above into the metadata design.  I *think*
the approach described will effectively work around the problems, but
welcome some feedback.

Regards
Bob

Attachment: split_dataelement.png
Description: PNG image