dhis2-devs team mailing list archive

[Saptarshi Purkayastha <sunbiz@xxxxxxxxx>]

2009/6/6 Bob Jolliffe <bobjolliffe@xxxxxxxxx>

> Hi Saptarshi
>
> Thanks for this.  (I had to load the uml extension into netbeans but
> it seems like a useful tools - much like argo in fact).


The advantage that an IDE should have as a design tool is that we can
generate code, make changes and reflect them back in design. All this done
in a RAD and integrated way... Thats why I love Netbeans and its
out-of-the-box features.


> A few comments and queries:
>
> First off its excellent to have a design diagram to work with.
>
> It looks like you have used ideas from the openMRS model which is also
> excellent.  It ensures you catch lots of traps like persons having
> more than one address, presenting with any variety of identifiers etc.
>  I gather from the setPreferred flag in personIdentifier that this
> really is the intention.  There is probably a good bit of tidying to
> do - like you are missing a list of identifiers from your Person class
> but that's fine.  How close is this to the openmrs model?  Would it
> for example allow the sharing of demographic data between the systems?
>  This might be useful to bootstrap one system in an area where the
> other is already established which is probably a good thing.  Mind you
> there should probably be strict procedures around sharing of
> identifying data between persons or systems.  But that is another
> matter ...


Yes, the setPreferred will let one select the favorite one from multiple
identifiers, address, name etc. Important because these change during a
person's lifetime. Demographic information is similar to OpenMRS and we
should be able to share the person information, but anything related to
Patient, Program has been left out, since we don't want to be in the EHR
territory. Only name-based service provisioning requires this much person
information to be scalable and generic.

And yes, a method of getIdentifiers() : List<PersonIdentifier> is missing
from the Person class which will return all known Identifiers for that
Person.


> You probably need to have Identifier type as well.  This would
> translate to a lookup table of common or likely candidates in the area
> - birth cert, national id card, health card etc (god forbid - maybe
> even iris scans :-)


Does make sense to add a PersonIdentifierType class. Will add that in the
next iteration.


> I am not sure about orgUnit being a field of patient identifier.  Of a
> particular type of identifier maybe ie. an orgunit issued id which
> might be a concatentation of orgunit id and that id (a file number for
> example).  But perhaps you are only considering this type of
> identifier in which case ok - ignore my comments above.  You should
> then maybe have a "date issued" field to cater for migrations.


The OrgUnit in the PersonIdentifier is useful because it will let us know
the new registrations under an OrgUnit instead of just the new person's
receiving services as part of an encounter. The Identifier generally is like
you said a concatenation.


> There is always a difficulty in deciding what should be a Person
> *field* and what should be a Person related *datavalue*.   I am not
> sure what best practice is around, for example sex, date of birth,
> date./cause of death.  Arguments can be made either way.  I suppose
> the advantage of having these as datavalues rather than person fields
> is that they can be made part of anonymous statistical queries without
> requiring to grant access to the identifying personal data. There's
> even an argument for storing it both as field and datavalue but you
> have data consistency problems.  Another approach is to separate into
> two tables - like "clinical person" and "identifiable person" with a
> 1-1 relationship.  You can have all these fields in the former and
> names and addresses in the latter.


Sex, date of birth are generally Person identifiable things. Names are same
and people don't remember Identifiers. Date of Birth is many times the
differentiator.


> I am a bit confused around what you mean by
> PersonType->servicesProvided->DataSet.  You might need to elaborate
> further on this.  What do you mean by a person type anyway?  Is it
> along the lines of patient, community member in receipt of service,
> nurse, ANM etc ...


According to a program the health worker provides services. From this list
of services, a health worker can choose to provide some service or the
activity plan can be created. The ANM, Patient, Family Member, Household are
all Person and they can be classified based on the PersonType


> I see the link to orgunit - and thus the beginning of the link back
> into DHIS - happens in the personRelation.  I'd have to think a bit
> more about this - at first blush it seems like too much detail.  Do we
> really need to know this?  If we do, then isn't this relation better
> captured in the activity register anyway?  Perhaps once we get the
> activity register and encounter on to the design diagram we will see
> better.


The PersonRelation is going to help find the default OrgUnit which should
provide service. But it may very well true that the Encounter may be had
with a ANM from a different OrgUnit... and it quite often happens for child
delivery and PNC in India.

All of this still has to be folded into the
> Encounter/ActivityPlan/DataValue/DataSet/OrgUnit/Source etc where
> there are still tricky design issues to be addresses but I think its a
> good start.


Abyot had a discussion on this and I think he has a clear idea, which he
passed on to me regarding ActivityPlan, Encounter and the rest. Encounter is
going to be the real link between CHIS and DHIS, but we could have other
types of aggregation services on Person data that can result into
aggregation.


> Any thoughts about how to store this data separately from the
> anonymous data?  We didn't get to discuss having more than one
> hibernate session.  Perhaps it is something Lars will get to in his
> service layer refactoring ...


I was discussing exactly this with Abyot and I felt unless we decide on a
separate Hibernate/JPA Session to do the plumbing, writing code won't make
much sense. Abyot feels otherwise and believes we will code to a single
connection+database until we can reach a consensus and Lars finishes the
refactoring.


>
>
> Cheers
> Bob
>
> 2009/6/4 Saptarshi Purkayastha <sunbiz@xxxxxxxxx>:
> > Please find the attached Class Diagram representing the Person and its
> > model... Its not exhaustive. It lacks constructors, constants and some
> other
> > parts that can be implemented in iterations. Also I have deliberately
> > avoided Generalizes, Implements, Depends and the other clauses from the
> > diagram because without the full design those are somewhat meaningless.
> > It does not have the ActivityPlanner, Encounter and PatientDataValue. I
> have
> > included something known as StaticDataValue in causeOfDeath (we can have
> > that as static DataValues that will not change. More like a Dictionary).
> > Similarly Dataset in servicesProvided is also a static Dataset (but not
> very
> > static, if that makes any sense ;-))
> >
> > Encounter is as much as we should get into a electronic health record
> (EHR).
> > Program, Patient, Regimen, Findings, Drugs and the rest should be
> ignored.
> > ActivityPlanner (a subclass of Dataset, as I understand) should be the
> basis
> > of Encounters. Encounter will have the orgunitid, personid, period etc
> which
> > is populated from the values in ActivityPlanner. I dont have a clear idea
> on
> > the details of that, but I am sure Abyot can represent that for us.
> > PS: I have used the Netbeans UML designer which is quite good for simple
> > designs. Not as powerful as Rational's tools, but good enough for our
> needs
> > . I have attached the Netbeans UML project for anyone who wants to edit
> or
> > make changes on this model.
> >
> > ---
> > 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>
> >>
> >> 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
> >>>>> >>>>>>>> >> >> 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
> >>>>> >
> >>>>> >
> >>>>
> >>>
> >>
> >
> >
>