dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

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.
So I'm guessing Abyot will make a PatientDataElement with something
like a patientID.

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?

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
>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dhis2-devs
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>
>