dhis2-devs team mailing list archive

[Ola Hodne Titlestad <olati@xxxxxxxxxx>]

On Wed, Jun 3, 2009 at 12:04 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:

> 2009/6/3 Ola Hodne Titlestad <olati@xxxxxxxxxx>:
> > Hi Abyot,
> >
> > If you read my summary e-mails just before the skype conference you will
> see
> > that my suggestion was NOT to have a different type of data element, and
> I
> > understood from the skype chat that we agreed on the same. What we talked
> > about was to possibly make a separation in the user interface to avoid
> > confusing the users, but in the background use the same DataElement
> object,
> > but I am not sure that will always be needed as there are lot of overlap
> > between routine and CHIS data elements.
> >
> > As you say, if we want to easily reuse datasets and data entry forms
> > functionality we need to use the DataElement object also for client data
> > elements. And of course we want to reuse what Murid has implemented
> > regarding option lists for pre-defined values for data elements.
> >
> > The separation comes in DataValue as the PatientDataValue will need other
> > properties than the (routine) DataValue.
>
> Agreed.  But what would these properties be exactly?  Two options
> which have surfaced are:
> 1. an additional patientID attribute; or
> 2. no additional attribute - association of patient as a "source"
>
> The first is most obvious and perhaps simplest.  And I suspect I am
> the only one crazy enough to see any merit in exploring the second.
>

patientID yes, but probably also a DataSetID as we need to keep track (and
separation) of the encounters/visits (instances of a dataset, "a filled
form") in a more efficient way than we do in DataValue now.
At least this is how its done in 1.4 Patient module and also for Survey type
data.



> So I'm guessing Abyot will make a PatientDataElement with something
> like a patientID.
>
Data elements do not have any direct reference to its source, so this should
not be necessary. It is the datavalue that keeps this reference and which
again is controlled by the dataset.
We would in stead need a maintain Patients/Clients in a separate object, and
pherhaps in a hierarchy (family, village). Lars also liked the idea of
implementing the source object here, and I am open to that. After all that
is why we created the source, to have diffeent types of sources to register
data, not only orgunits.
The peirod handling might also be different here as we always work on dates
since these data are snapshots in time and not aggregtated over a certain
period.

Calle might have some useful input to how patient values are different from
routine, apart from the security aspect we already discussed some weeks
back.


>
> What else?  Do we need a concept like an encounter (or visit) to which
> a date would be tied?  Or can something be done with a PeriodType?
>

If we are going to reuse the DHIS concepts of data element, dataset, data
entry form and data value then the dataset is the key here.
In many ways routine datasets and "client" datasets are very similar, and "a
filled form", or what might be called an instance of a dataset, contains
values linked to data elements for a given period and a given source. Client
encounters, rows from a register book, are also like that; a client name,
multiple data elements (columns in the book) with values, and a date. After
all its the final row of the register book, the total row aggregating all
the encounters that gives the routine values for a monthly routine dataset.
This example also illustrates how data elements overlap between client data
and routine data, routine data are simply the total of "all clients" for the
month. (This is not the case in survey audit type of datasets e.g. with
maternal detah audits, but for standard CHIS it is mostly the case)

If we keep track of the DatasetID in a ClientDataValue object we can the
easily get an ecounter by querying for a client + a date + a dataset, or a
list of all encounters (within a certain programme (dataset)) by querying
for a client + a dataset. Of course it would be possible to get all data
elements belonging to a dataset without directly referencing datasetid in
datavalue, we do that today for dataset reports. Again, we need to check
this with Calle or others, but I think client data are different in the way
that a data element can exist in multiple datasets AND be registered for all
of them for the same client and date, because the same data elements in
different datasets might have different meanings and values. For routine
this is not the case, that is why we di not keep a reference to dataset in
datavalue, it is enough to use data element to describe the meaning of the
data.

So each encounter will be a data entry form, and its metadata will be
controlled through the dataset object, similar to how its done for routine
data. In the dataset object we need to specify what kind of data that is
going to be registered,e.g. aggregated, disaggregated, survey(or routine,
client, survey). Semi-permanent is then included in routine which is a bit
confusing, that is why I prefer aggregated. Anyway, the principle is the
same.

Datasets could be made even more dynamic, as we discussed on Skype, by
adding other attributes like a set of header data elements and a set of
footer data elements. These will be based on the same type of data elements,
but stored or treated in a different way (in data entry and data
value).Exactly how I am not sure, but we should look in detail at how 1.4
treats header data elements.

Ola
--------










>
> Regards
> Bob
>
> > And we also talked about the need to extend the DataSet object to include
> > more properties that makes datasets more flexible and dynamic as we need
> > them for CIS and also for survey data.
> >
> > So here I guess we all agree, there is no need to come up with a separate
> > PatientDataElement.
> >
> >
> > best regards,
> > Ola Hodne Titlestad
> > HISP
> > University of Oslo
> >
> >
> > On Wed, Jun 3, 2009 at 11:26 AM, Abyot Gizaw <abyota@xxxxxxxxx> wrote:
> >>
> >> Hi All,
> >>
> >> Couldn't really convince myself as to the need to keep a separate track
> of
> >> dataelements called patientdataelement. I just did an implementation for
> >> patientdataelement ... but when giving it a thought about linking it
> with
> >> some custom and predefiend values, then I see that one already in place
> by
> >> Murod for the routine dataelements. And if we are going to have a case
> of
> >> like recording multiple values for a single patient dataelement, then we
> >> also will redo all the compex task of linking with options, categories
> and
> >> their combinations, which is again in place for the routine
> dataelements.
> >>
> >> If the need to separate the two - routine and patient is only for the
> >> purpose of managment, then I think it will be better if we could
> introduce
> >> an attribute called 'classification' for dataelements. With this
> attribue we
> >> can classify our dataelements like - Routine, Patient, Header,
> Footer,...
> >>
> >> Any input will be appreciated.
> >>
> >> Thank you
> >> Abyot.
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
> >> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> >> Unsubscribe : https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
> >> More help   : https://help.launchpad.net/ListHelp
> >>
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
> > Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
> > More help   : https://help.launchpad.net/ListHelp
> >
> >
>