dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

Hi

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".

Agreed.  Is there a favoured dhis2 uml tool I wonder?  We can surely
share the pictures but it would be good to use the same tool.

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

We do need a diagram here!  Think Source rather than OrgUnit.  .If you
look at dhis-api/src/main/java/org/hisp/dhis/source/Source.java  you
will see that a Source is nothing more than a wrapper for an
Identifier.  So a rich model for a person (like for example the
OpenMRS demographic model) can extend Source in exactly the same way
OrgUnit does.  This doesn't make Person an OrgUnit or an extension of
one.

The main benefit being we might then be able to reuse datavalue as-is
which I think would be good.  Without it, we resort to creating a new
PersonDataValue which would perhaps be tolerable but not ideal.

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

Agreed.

Regards
Bob

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