dhis2-devs team mailing list archive

[Abyot Gizaw <abyota@xxxxxxxxx>]

I guess we all agree with this - I agree!

On Thu, Jun 4, 2009 at 12:45 PM, Ola Hodne Titlestad <olati@xxxxxxxxxx>wrote:

> Hi guys,
>
> Sorry to hear that many of you are not able to follow the discussion, I'll
> try to spell out more clearly what my main concerns and interests are.
>
>
> First of all. I still have a feeling that the community/home/family part of
> the requirements are perhaps blocking or at least interfering with other
> important usage of this module. But maybe it’s just a misunderstanding. I’ll
> discuss this with Abyot face2face (since we are sharing office…) soon, but
> first some lines to the list (sorry for terrorising you on this topic).
>
> *Orgunits (the main owner of data in a DHIS system)
> *I can't stop talking about orgunits because to me they are the key link
> between a routine system and a “client-extended routine system” (which I
> think it what we are developing, as opposed to a fully fledged medical
> records system (OpenMRS is a much better candidate there).
>
>
>
> We need a system where we can “follow the data” in further detail than in a
> normal routine system, either by looking at individual clients being served
> by the facility (at home or at the clinic) as part of health programme
> services, or by looking at more detailed data about a specific vital event (
> a death, a birth, or an outbreak) taking place at a facility or in it’s
> catchment area.
>
>
>
> So while we need to collect data at the client level we still need to keep
> track of the orgunit responsible for the service, whether the service is
> carried out as part of a home visit in a facilities catchment area or at the
> health facility itself.
>
>
>
> Those essential needs make up the minimum common denominator for all the
> requirements and use cases we have discussed so far. Hopefully also when we
> include Jason’s requirements from Zambia…let’s see.
>
>
>
> As long as I can be sure that we agree on those basics, and that the
> following functionality is taken care of, I will stop interfering the
> detailed design discussions and hopefully let the coding of the prototype
> begin:
>
> Basic functionality for CHIS:
>
> 1) allow for data to be collected that has no reference to house, family or
> community, but simply a patient identifier and a clinic (this is needed for
> vital events registration)
>
> 2) enable quick drill-down from facility to client level when analysing at
> data (“moving from the routine monthly report to the register book”) – the
> main advantage of doing this CHIS inside DHIS
>
> 3) provide a user-defined and easy to use model for generating aggregated
> data based on client-data (extending the calculated data element approach,
> to create statistics and indicators from vital events)
>
> 4) Generation of routine data values (dataelement, orgunit, period).
>
> 4a) using the “extended calculated data element approach” (vital events
> etc, see my examples on Maternal Death audit from pervious mails)
>
> 4b) in a community setting simply reuse the dataelements from the register,
> but aggregated up to a facility and a month (or other desired PeriodType)
>
> * *
>
> *Activity Planning and client tracking*
>
> On top of that, but equally important,  we have the requirements to support
> the health programs in carrying out their home visits;
>
> 1) by providing activity plans with specific encounters/activities (where,
> when and what) that has to be carried out,
>
> 2) the ability to track a client as see his/her status within a specific
> programme, as to which vaccines are missing, checkups needed etc.
>
> I am not saying that we should not prioritise the Activity Planning
> functionality here, of course we need that as part of the first prototype,
> it is simply a separation of functionality to more summarise the needs from
> all the use cases, and to try to map out what I see as the basics that are
> shared by all the use cases we try to cover with this module.
>
>
> best regards,
> Ola Hodne Titlestad
> HISP
> University of Oslo
>
>
> 2009/6/4 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
>>> >
>>> >
>>>
>>
>>
>