dhis2-devs team mailing list archive

[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
>> >> >
>> >> >
>> >
>> >
>>
>
>