dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

2009/6/4 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.

Just had a go at importing dhis-api classes into argouml. Its a bit
messy but can work.

Regards
Bob

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