dhis2-devs team mailing list archive

[Jason Pickering <jason.p.pickering@xxxxxxxxx>]

I too have been silently following the discussion, understanding
little about what has been discussed, and having a number of
trepidations about what was discussed. I was unfortunately not able to
join the Skype conference last week, as I was out in the field and had
not internet access. I wish I could have been there.

Anyway, I could not agree with Saptarshi more. The various discussions
need to be distilled down into a diagram as soon as possible. I have
some different ideas about how such a module (or what it seems to be
morphing into a separate application) should work, based on
requirements that have been expressed here in Zambia, which seem to be
very different from the discussion that I have been following over the
past few weeks.

Could we maybe setup something on Launchpad to allow this to start happening?

Regards,
Jason




2009/6/4 Saptarshi Purkayastha <sunbiz@xxxxxxxxx>:
> I was silently following the discussion, because I am having a hard time
> trying to understand what is being discussed. I was hoping to understand the
> ideas as things were discussed more. Some clever guys invented diagrams (UML
> and the like) for modelling and "Picture do speak a thousand words".
> As for Encounters, these should be treated as anything where a Person
> (health worker, patient, household or family) has received a service. Death
> audit on the other hand is not receiving of a service (death during delivery
> or immunization can be recorded as part of an encounter). Instead the real
> audit of death should come from a Person's state (OOP speak: fields) and
> should be accessed as behaviors (OOP speak: methods). The Person should have
> deathDate, causeOfDeath just like a Person has birthDate, name and address.
> Ideally, Encounters should be filled in (or simply adding a "checkmark",
> that it was done) from an ActivityPlanner dataset. Thus the ActivityPlanner
> is a dataset and after values have been filled (or checkmark added) into it
> by using the EncounterService, it becomes an Encounter. ActivityPlanner is
> generated from the ActivityPlannerService, which gets its data from another
> dataset.
> @Ola: I do not agree to the notion that Person can be considered as an
> extension of the OrgUnit. Person should have something of a relationship
> with an OrgUnit just as a Person should have relationship with other Person
> and only Person should have an Encounter, not an OrgUnit.
> PS: A UML representation is needed before we can code, to summarize what has
> been talked about till date about the design because everyone (including me)
> have been forgetting what was decided and what was debated.
>
> ---
> Regards,
> Saptarshi PURKAYASTHA
> Director R & D, HISP India
> Health Information Systems Programme
>
> My Tech Blog:  http://sunnytalkstech.blogspot.com
> You Live by CHOICE, Not by CHANCE
>
>
> 2009/6/4 Abyot Gizaw <abyota@xxxxxxxxx>
>>
>> No it will not be generated by an activity planner service. It will have
>> its own service I don't know may be encouterSevice or something like that.
>> But Activity planner is going to make use of Encounters. As you mentioned
>> the whole world doesn't go by the plan but as far as Health Extension
>> program is concerned then that is the reality. I mean health workers will be
>> given a sheet of paper list of names together with house numbers and the
>> kind of service they are going to provide on the date specified.
>>
>> Now to the auditing thing, forget for the time being the activity planning
>> or the community thing. I have seen a 1.4 patient module. When ever you
>> click on the person icon and new pop up window opens with a list of items to
>> be populated inluding the name of the person. I think this for me is an
>> Encounter. A clincian has been waiting for a patient to arrive, a patinet
>> arrives and the clinican picks a piece of paper/form to register the
>> incidence - could be death, birth or immunization or generally a treatment.
>> For me this is an encounter which got shaped dyanamically (for example the
>> individual identified during the point of care). And just like paper forms
>> (for recording such an incidence) are printed before hand like a template,
>> then a dataset (the current one)  will be used as a template to generate a
>> more advanced and dynamic one called Encounter
>>
>> The activity planner by no means introduced the Encounter. I don't know
>> may be I got influenced by OpenMRS, at least on this Encounter thing. That
>> is how they modeled it - Saptarshi can you comment on this?
>>
>> Thanks
>> Abyot.
>>
>>
>> 2009/6/3 Ola Hodne Titlestad <olati@xxxxxxxxxx>
>>>
>>> 2009/6/3 Abyot Gizaw <abyota@xxxxxxxxx>
>>>>
>>>> Nooooo - I mean the point you mentioned that Encounter got introduced
>>>> because I wanted to have it for the activity plan generation. No that is not
>>>> the reason. And I didn't really understnad the data Vs metadata and also
>>>> dhis design Vs activity/paln mixup I made.
>>>
>>> What confuses me (but less after your last email) is that you want to use
>>> Encounter both as an Activity and as kind of "data table". Let's see if  I
>>> know understand you correctly:
>>> An Encounter is generated by "an activity planner service" based on a
>>> dataset and a plan (who to visit and when) and then an instance of an
>>> Encounter would contain a specific value for source, patientID and date
>>> right and would be what I call a planned encounter, right?  And after the
>>> encounter has been made there will data values in PatientDataValue linked to
>>> the Encounter, right?
>>>
>>> So you can say that there is a two step process in "populating" a
>>> "complete patient data value", first you populate the Encounter with source,
>>> patient and date (which can happen any time), and then at the time of data
>>> entry or import you populate the PatientDataValues and reference the already
>>> exisiting encounter. Is this correct?
>>>
>>>>
>>>> Anyways, I could be wrong in my proposition. But the reason I brought
>>>> the idea of Encounter is a simple normalization of patientdatavalue. Imagine
>>>> a row in a datavalue table
>>>>
>>>> (patientid,date,sourceid,dataelementid,optioncomboid,value)
>>>>
>>>> and the first 3 columns will be the same for an individual say for
>>>> example for hundredes of dataelements collected in a specific instance of
>>>> patient's diagnosis or treatment or actually an encounter. so patient,source
>>>> and date are I feel unqiue in describing an encounter - that is how I
>>>> introduced Encouner. In addition, this apporach will avoid direct linkage of
>>>> a patient to his/her sensitive data. And of course an Encounter is a valid
>>>> concept, I feel, in the CHIS we are trying to develop.
>>>
>>> I can see the need for normalisation, although I assume you could argue
>>> that this is also the case with normal routine data values in DHIS, and
>>> there we chose not to do this. Is it worth to break with this design or not,
>>> that is what I am asking I guess. Why use a different apporoach here than
>>> for routine data when I think it would be easier for all involved if we
>>> streamlined approaches to data stroring. Of course if there are better
>>> reasons (maybe you have already mentioned them and I simply don't understand
>>> them) for normalisation of client data than with routine data, if so I will
>>> no object it, but as a general principle I think we should follow the same
>>> design approach were feasible. But not at any cost of course.
>>>
>>> My main concern is that the concept of Encounter, at least to me only
>>> seems to fit with the community part of this module and not with the
>>> audit/case-based part. E.g. with the use case from Zanzibar (and many other
>>> places) where you want to collect data about a Maternal Death there will be
>>> no encounter, but an audit form that is filled after the death occurred, or
>>> similar with other vital events like births or with notifiable disease
>>> notification where you collect a lot of detail about a specific new case. In
>>> this case I guess you can also argue for normalisation and keep metadata
>>> (patient,source, date) about the "event" in a separate table, but to me the
>>> name "encounter" seem wrong in this scenario.
>>>
>>> I know it is hard to make one design fit all these cases perfectly, but
>>> my hope was that we could come up with a generic data model for collecting
>>> and storing patient data that would work for both community registers and
>>> for audits on vital events (death, birth, case of notifiable disease), and
>>> then build on such a "basic patient model" what you need to conceptualise
>>> encounters and activity plans.
>>>
>>>>
>>>> Infact this approach is more scalable than what you are mentioning ...
>>>> because at some point we may need to go through encounters and deal with
>>>> history. by then we can add more attributes to enounters and expand
>>>> functionalities.
>>>
>>> which I guess will move them even further away for other usage than for
>>> community registers
>>>>
>>>> probably we need to draw a line - I mean with aggregate systems Vs
>>>> individual/patient based systems --- because the direct manipulation of data
>>>> makes sense for aggregate systems. And for the case based (or Individual)
>>>> systems then I think we need to depend on queries or services to be provided
>>>> by the system for aggregation or manipulation of data.
>>>
>>> ok, I guess I see it from the other side; that we could keep the same
>>> design for data values, but add new services to represent encounters,
>>> registers, plans etc. on top of that
>>>
>>>
>>> Ola
>>> ----------
>>>
>>>>
>>>>
>>>> Thanks
>>>> Abyot.
>>>>
>>>>
>>>> 2009/6/3 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
>>>>>>>> >> >> 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
>>>>>>>> >> >
>>>>>>>> >> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>> _______________________________________________
>> 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
>
>