dhis2-devs team mailing list archive

[Ola Hodne Titlestad <olati@xxxxxxxxxx>]

Hi,

Sorry, maybe I'm a bit slow, but I don't manage to follow this reasoning.

First of all I get a bit confused as to what is metadata and data in your
model Abyot. Now it seems you have split up data values for patient data
into two objects, Encounter and PatientDataValue, is that right? I can see
that PatientDataValue does no longer have a refenece to place or time, but
that this is taken care of through an Encounter.

If that is the case then we will not get the straight forward calculation of
aggregated data that we would have with Date (easily up to month) and
Orgunit (group data values by orgunit) in PatientDataValue, which I would
not recommend, especially for other use cases like birth/death audits or
disease surveillance.

(Guess I forgot to mention the orgunit reference from patient data value
earlier today,although it has been mentioned before. It has many advantages
when zooming in and out between aggregated and disaggregated data.)

But from your description of an Encounter as part of the tasks carry out in
the generated activity plan I got the feeling that Encounter is metdata
describing HOW to collect the datavalues as is the case with data sets.  "By
whom" and "when" in Encounter, seems to be information belonging to a data
value, and not metadata. If the references to Whom and When in Encounter are
"planned values" something you are supposed to do then I get it, but then I
guess we cannot use the same values as part of the data value, I mean the
world does not always go according to the plan. Maybe you just forgot to add
a reference to PatientID and Date (and Source maybe) in PatientDataValue, if
so then it would make sense to me.

I am not sure I like how you model mixes activities and plans with the
straightforward DHIS design of data elements, datasets, datavalues. Could
your planned activities be linked to dataset, patient, and source without
interfering with dataset and datavalue? That would keep the model simpler
and easier to use for other use cases where we ant to collect case-based or
client data.

An Encounter or a register, isn't that simply a view on top of patient data
values (filtered by dataset, date, patient), similar to a dataset report in
routine DHIS? I understand the importance of referencing the encounter from
the datavalue, but not sure I see the point of this dataset+encounter
design. Your Encounter object sounds more like an Activity object which is
stricty metadata (that says something of what you plan to do) and not a
regsiter/encounter (which says what have been done) that has values for a
patient, date and a set of data elements.

best regards,
Ola Hodne Titlestad
HISP
University of Oslo


2009/6/3 Abyot Gizaw <abyota@xxxxxxxxx>

>
>
> 2009/6/3 Abyot Gizaw <abyota@xxxxxxxxx>
>
>> A bit tricky!
>>
>> I think we need to maintain both Encounter and DataSet. I mean, a DataSet
>> evolving to an Encounter whenever a visit is made by either a patient or a
>> health-worker. This will help us to implement a dynamic DataSet
>> functionality.  And here the DataSet will be acting only as a template to
>> guide an Encounter.
>>
>> ·         DataSet
>>
>> o   Source
>>
>> o   Period (for CHIS, daily periodType)
>>
>> o   set<DataElement>
>>
>>
>>
>> ·         ActivityPlan
>>
>> o   Owner – person (Health Extension Worker)
>>
>> o   Supervisor – person (Medical Officer)
>>
>> o   Date – date
>>
>> o   Activities – set<Encounter>
>>
>>
>>
>> ·         Encounter  *implements* DataSet
>>
>> o   Where – source (could be house or facility or anything else…)
>>
>> o   When – date (time stamp)
>>
>> o   ByWhom – person (the patient)
>>
>> o   What – set<DataElement> (list of data to be collected)
>>
>> Sorry for the above strange stuff. I think it is better like down below.
>
>
> ·         Encounter
>
> o   DataSet
>
> o   ByWhom – person (the patient)
>
> o   When – date (time stamp)
>
>
>>
>> ·         PatientDataValue
>>
>> o   EncounterID
>>
>> o   DataElementID
>>
>> o   OptionComboID (just in case we are going to collecet multiple values
>> for a dataelement)
>>
>> o   Value
>>
>> Activity plan is linked to an Encounter because during a house-to-house
>> visit, health-workers are to follow a strict plan, signed by her/his
>> supervisor outlining whom to meet, where, when and what kind of service to
>> give (or what kind of data to collect).
>>
>> The above approach will help us to do scheduling/tracking which I guess
>> are very much linked to Encounters. For example a Mother need to be
>> scheduled for a 2nd ANC Encounter following her 1st ANC Encounter, or
>> similarly for Child Immunization.
>>
>> The dataelement classification is only to have a nice and tidy list of
>> dataelements on the GUI, for example not showing patient related
>> dataelements in indicator or datamart processing - which is a nice idea of
>> Ola. The classification will have no use for the functionality of CHIS.
>>
>> Thanks
>> Abyot.
>>
>> On Wed, Jun 3, 2009 at 2:04 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx>wrote:
>>
>>> 2009/6/3 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.
>>>
>>> Sorry typo - I meant PatientDataValue ..
>>>
>>>
>>> > 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.
>>>
>>> OK.  This makes sense.  A register object (for want of a better term)
>>> would be a specialisation of dataset.
>>>
>>> > 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.
>>>
>>> Trying to piece together what a register might look like in xml:
>>>
>>> <register name="Immunization register">
>>>    <dataset name="header" >
>>>       <dataelement name="????" >
>>>             <datavalue source="[clinicID]" period="???" value="34" />
>>>       </dataelement>
>>>       <dataelement name="????" >
>>>             <datavalue source="[clinicID]" period="???" value="34" />
>>>       </dataelement>
>>>    </dataset>
>>>
>>>   <patientdataset name="immunization data" />
>>>        <dataelement name="???">
>>>             <patientdatavalue source="[patientID1]" value="36"
>>> date="01/01/2010" /> <!-- should date be done with a period type?
>>>             <patientdatavalue source="[patientID2]" value="43"
>>> date="01/01/2010" />
>>>             <patientdatavalue source="[patientID3]" value="35"
>>> date="01/01/2010" />
>>>             <patientdatavalue source="[patientID4]" value="22"
>>> date="01/01/2010" />
>>>        </dataelement>
>>>        <dataelement name="???">
>>>             <patientdatavalue source="[patientID1]" value="36"
>>> date="01/01/2010" />
>>>             <patientdatavalue source="[patientID2]" value="43"
>>> date="01/01/2010" />
>>>             <patientdatavalue source="[patientID3]" value="35"
>>> date="01/01/2010" />
>>>             <patientdatavalue source="[patientID4]" value="22"
>>> date="01/01/2010" />
>>>        </dataelement>
>>>   </patientdataelement>
>>>
>>> </register>
>>>
>>> While typing the above it occurred to me that header AND footer are
>>> probably not necessary for representing a register.  What we really
>>> need is a set of dataelements associated with the register and a set
>>> associated with register rows.  Whether the elements in the former are
>>> eventually rendered in the header or the footer is probably a
>>> presentation issue which could be determined by, for example, the name
>>> or ID of the dataelement.
>>>
>>> Also the above patientdataset is grouped on the dataelement axis.
>>> Could also be grouped on source/patientID, making it closer in analogy
>>> to rows in a register.  Though deriving the latter from the former is
>>> a simple enough transformation.
>>>
>>> Abyot, returning to your original question, I don't know if having a
>>> dataelement classification is necessary.  If the dataelements are
>>> always members of a dataset (at least one or only one ..) then
>>> probably not.  But I think you are right that it is only as you hammer
>>> out the detail that the truth might emerge ...
>>>
>>> Cheers
>>> Bob
>>>
>>> > 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
>>> >> >
>>> >> >
>>> >
>>> >
>>>
>>
>>
>