dhis2-devs team mailing list archive

[Abyot Gizaw <abyota@xxxxxxxxx>]

Hi All,

Please find the attached diagram though not complete. Saptarshi, you can
extend the diagram after sorting out the details with person,
house/orgunit,...

Looking for your comments.

Thank you.
Abyot.


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

Attachment: chis_diagram.pdf
Description: Adobe PDF document