2009/6/3 Ola Hodne Titlestad <[email protected]>: > 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 <[email protected]> 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 : [email protected] >> Unsubscribe : https://launchpad.net/~dhis2-devs >> More help : https://help.launchpad.net/ListHelp >> > > > _______________________________________________ > Mailing list: https://launchpad.net/~dhis2-devs > Post to : [email protected] > Unsubscribe : https://launchpad.net/~dhis2-devs > More help : https://help.launchpad.net/ListHelp > > _______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
