dhis2-devs team mailing list archive

[Abyot Gizaw <abyota@xxxxxxxxx>]

Yes we are getting closer and we have to.

And yes the patientdatavalue has no link at all to the plannedhouseholdvist.
Initially the patientdatavalue has a link to encounter which exactly
determines when,for_whom and what. But for the reason I mentioned in my
earlier mail this link is removed from patientdatavalue - though I don't
agree with the removal I have removed it.

But Bob I didn't get the point when you say we will lose information. I
thought we will rather have a redundant information - the source, patient,
dataset and date all registered in both plannedhouseholdvisit and
patientdatavalue.

hew = Health Extension Worker in the global context and specific to India
ANM (Auxilary Nurse Midwife).

And a little more clarification, probably for Saptarshi too, when an
activityplan is generated it first needs to be approved and signed by a
Medical Officer or a Supervisor and then assigned to a specific HEW/ANM so
this is the reason I introduced hew and supervisor for ActivityPlan. Both
hew and supervisor are users as far as DHIS is concerned because these
people will login to the system and enter values, define datasets and lots
of other operations so I thought using the existing User object will make
sense. And the remaining are individuals to be visited during house-to-house
or when they show up to a clinic or for the case of Zanzibar those who are
dead, and treating these people using a "Person" object didn't comfort me
... because both hew and supervisors are also persons. That is why I used
the object Patient for these individuals .... of course don't forget that
there are lots of things which I am not comfortable with but it is ok as far
as that is the way forward.

Saptarshi, yes both ANMs and Supervisors will at some point get treatment in
their house or clinic but the User object only keeps username/password and
very little personal information compared to demographic information. So I
feel it is ok if these people got registered both in our user table and
patient table. With the approach you suggested using Person (by the way I
like the object person), personType and lots of attributes attached to it -
I am a little bit afraid that we will make things hard for ourselves. I
don't know that is how I felt - you have put lots of attributes to a Person
!

Thank you
Abyot.

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

> OK.  We're gettig closer ....
>
> 2009/6/8 Abyot Gizaw <abyota@xxxxxxxxx>:
> >
> >
> > 2009/6/8 Bob Jolliffe <bobjolliffe@xxxxxxxxx>
> >>
> >> I'm not sure if this counts as an insight but at first pass, there is
> >> very little between these two diagrams other than what was previously
> >> labelled an Encounter is now labelled a HouseHold visit.  I have no
> >> problem with that - given the possible interaction with openMRS its
> >> probably a good idea to use a distinct terminology for this thing.
> >>
> >> Other than that can someone explain the difference between Encounter
> >> and HouseHoldVisit? [I think I might have answered myself by the end
> >> of the message but I leave the train of thought here anyway]  In the
> >> new case we can have an ActivityPlan which contains a set of
> >> HouseHoldVisits.  The original idea it seems was that a plan would
> >> contain unfulfilled visits.  That idea seemed OK to me.  You are
> >> either going to have a list of planned visits from which concrete
> >> HouseHoldVisits are instantiated at the point when the visit is
> >> recorded, or you have a list of HouseHoldVisits which start off life
> >> in an unfulfiulled state and are "hydrated" when the visit is
> >> recorded.  What is being suggested now?
> >>
> >> looking aside from the Encounter, there seems to be a more fundamental
> >> change proposed with the PatientDataValue.  Whereas before the source
> >> and period (date) were effectively being inferred from the Encounter,
> >> now they are being tied more directly to PatientDataValue.  This is
> >> interesting and I can only imagine at the to-ing and fro-ing of debate
> >> which leads to this :-)
> >>
> >> I think the former makes more sense from a database perspective - the
> >> PatientDataValue is *always* captured in the context of an encounter
> >> (or HouseHoldVisit) so the source and period can be looked up from
> >> there.
> >>
> >> The latter has the attraction of being closer to the existing DHIS2
> >> DataValue.  Though I'm not sure how much advantage there is to being
> >> similar to, if it is not the same.  My own sense would be (i) either
> >> to make it the same as as a DataValue (not have a special
> >> PatientDataValue type, by hook or by crook) or (ii) go for Abyot's
> >> initial diagram.
> >>
> >> I know there has been some talk about them being similar, but one way
> >> in which DataSets are very different to Encounters is that we don't
> >> actually ever store instances of "dataset collection moments"
> >> currently.  We just save the datavalues.  Thats why we have to also
> >> save source and period with the datavalue.  And the DataSet is
> >> inferred as some function f(DataElement, Source, Period).  Presumably
> >> if we also currently saved the "dataset collection moment" (or
> >> SavedForm) we would have something close to an Encounter (or HouseHold
> >> visit).  DataSets are sets of DataElements whereas HouseHold visits
> >> are sets of DataValues.  Or perhaps this is the piece of the
> >> discussion I am missing.  In the new incarnation are we really saying
> >> that a HouseHold visit is a type much more like an existing DataSet?
> >>
> >> Regarding your last point on OO and diagrams, maybe you need to draw
> >> in the relationship with DataSet in each of the two cases to clarify
> >> ie. the first move from boxes to associations.  Does a HouseHoldVisit
> >> have a DataSet or is HouseHoldVisit a DataSet?  That for me seems to
> >> be the underlying difference between the two proposed models.
> >
> > I thought drawing the lines will be messy. But from the boxes and the
> > attributes shown for the newly added objects - HouseHoldVisit has a
> DataSet.
> > It was also the same in the previous case that Encounters have DataSets.
> >
> > The other point (or clarification) you asked is
> >
> > 1. "DataSets are sets of DataElements"
> > 2. "HouseHold visits are sets of DataValues"
> >
> > The first one is correct that DataSets are sets of DataElements. But the
> > second one is not. HouseHold visits are only sets of different objects
> which
> > determine a specific household visit that is why they contain the house
> to
> > be visited, the specific list of dataelements to be collected(as a
> dataset)
> > the person to be contacted(or examined) and the planed visit date. Once
> the
> > healthworker is out to the field as per the listed household visit plan
> > (which is populated in the ActivityPlan) then he/she will persist the
> > collected value on the patientdatavalue table. Instead of a HouseHoldVist
> > just Plan would have made a perfect sense as far ar naming is concerned.
> Or
> > shall we call it HouseHoldVisitPlan?
>
> I think PlannedHouseHoldVisit makes sense.
>
> >And in this case we will have one
> > monthly plan called ActivityPlan in most case 2 or 3 A4 papers each one
> > listing down specific houses and scheduled household visit plans together
> > with planned visit dates.
> >
> > probably another clarification HouseHoldVist has a source specifically a
> > house and a period again specificall service_delivery_date.
>
> So my only remaining question then is why do both the PatientDataValue
> *and* the PlannedHouseHoldVisit have a source and date?  Is it because
> the PatientDataValue has no link at all to the PlannedHouseHoldVisit
> in this new scheme.  The PlannedHouseHoldVisit simply determines the
> DataSet which defines the dataelements to be collected.  But it is not
> captured that they were collected within the context of a particular
> HouseHoldVisit.  Perhaps this is not necessary but this feels like we
> are losing information which we had in the paper register.  I think I
> preferred your first incarnation in this regard.
>
> Regards
> Bob
>
> PS.
> What kind of User is a "hew"?  I think I can guess but better spell it
> out more verbosely.
>
> >Whereas the
> > Activity plan is going to have a source either Village or PHC and then a
> > period just a month.
> >
> > Thank you
> > Abyot.
> >
> >>
> >> Regards
> >> Bob
> >>
> >> 2009/6/8 Abyot Gizaw <abyota@xxxxxxxxx>:
> >> > Dear all,
> >> >
> >> > And yet another diagram :-)
> >> >
> >> > This time the concept of Encounter is completely dropped from the
> >> > PatientDataValue for a reason which Ola thought that our approach
> should
> >> > be
> >> > similar to that of DHIS 1.4 patient module. Unfortunately I don't
> agree
> >> > with
> >> > this ... in any case I have attached you the new model. According to
> Ola
> >> > the
> >> > ActivityPlan need to work with plan not with half-filled encounters
> and
> >> > I
> >> > thought that it doesn't make sense to have two objects called
> >> > ActivityPlan
> >> > and Plan which I think is quite difficult to visualize the difference
> >> > and
> >> > similarity and hence I have given them a new name called ActivityPlan
> >> > and
> >> > HouseHoldVisit. This makes the concept of Encounter totally
> irrelevant.
> >> >
> >> > And if anyone has another view/insight please come up with a more
> >> > concrete
> >> > diagram close to an Object Oriented code than a list of description or
> >> > argument. I think doing that will speed up the whole process.
> >> >
> >> >
> >> > Thank you
> >> > Abyot.
> >> >
> >> > 2009/6/6 Abyot Gizaw <abyota@xxxxxxxxx>
> >> >>
> >> >> Hi,
> >> >>
> >> >> Please find the attached for your comment. In addition, I will be
> happy
> >> >> if
> >> >> I could get your view on how to generate activity plans.
> >> >>
> >> >> The idea I have, sort of use case, is for users to browse through the
> >> >> orgunits and reach to a village level. This is very important as
> >> >> activityplans are made every month for a village and approved by a
> >> >> village
> >> >> supervisor before they got passed on to the 2
> health-extension-workers
> >> >> a
> >> >> village has. Now, once a level is reached to a specific village then
> I
> >> >> am
> >> >> thinking of getting the list of houses for that village. Assuming
> that
> >> >> houses are extension of sources then I think it will be easy to
> >> >> indentify
> >> >> the latest encounter (actually a list of encounters) that happened in
> a
> >> >> given house for whom (patient) and what_kind_ of_service(dataset) -
> >> >> because
> >> >> Encounter has (source,dataset,date,patient) attributes.
> >> >>
> >> >> Departing from such a (history of) encounter then it is possible to
> >> >> determine what will likely be the next encounter - for example give
> ANC
> >> >> cylcle 2 for individual so_and_so located in a house (source) xxx for
> a
> >> >> probable date of xxxx. Such an Encounter, the one put on the
> >> >> activityplan is
> >> >> a half-completed that is why I put a boolean attribute completed
> (with
> >> >> default false). So once a HEW goes out as per the plan and provide
> the
> >> >> service - registering all the required values (like date, values for
> >> >> the
> >> >> specific dataelements) then we are going to have a completed
> Encounter
> >> >> which
> >> >> should later be reflected on the patientdatavalue table. Reflecting
> >> >> this on
> >> >> the patientdatavalue could be either when an sms is sent from a HEW's
> >> >> mobile
> >> >> or when a HEW comes with a filled (executed) activityplan. I am also
> >> >> trying
> >> >> to address the issue of migration here .... but at the same time keep
> >> >> in
> >> >> mind that Health-Extension-Program deals with house-to-house service
> >> >> delivery. Probably this will force us to say a person without a house
> >> >> will
> >> >> not be in the Health-Extension-Program - actually these persons will
> be
> >> >> entertained in the other use case; the one Ola described us nicely.
> >> >>
> >> >> Obviously this is about house-to-house tracking or service delivery.
> >> >> When
> >> >> you take out the activityplanning part then .... it will boil down to
> >> >> the
> >> >> use case of Zanzibar and Line-Listing. An incidence occurs (could be
> >> >> death
> >> >> or birth or what so ever) then we can simply launch an encounter
> sheet
> >> >> (the
> >> >> look of an encounter sheet is going to be shaped by the dataset it
> has)
> >> >> and
> >> >> record a new Encounter and then regsiter the specific values on the
> >> >> patientdatavalue.
> >> >>
> >> >> Thank you,
> >> >> Abyot.
> >> >>
> >> >> 2009/6/6 Saptarshi Purkayastha <sunbiz@xxxxxxxxx>
> >> >>>
> >> >>> Hi Bob,
> >> >>> Thanks for the comments and some really good insight about
> information
> >> >>> security which we need to think before implementing anything.
> >> >>> 2009/6/6 Bob Jolliffe <bobjolliffe@xxxxxxxxx>
> >> >>>>
> >> >>>> I think the main difference is that it is unlikely that one would
> >> >>>> ever
> >> >>>> want to query how many people called John have received a
> particular
> >> >>>> intervention.  But you might want to do that sort of query with
> males
> >> >>>> over the age of 6 or what have you.
> >> >>>
> >> >>> Nah, not about querying and aggregating based on name, but for
> >> >>> identifying the person. Suppose the ANM has to provide service to
> Mr.
> >> >>> Sagar
> >> >>> Shah of Mahindra Nagar (that's my locality). You will be glad to
> know
> >> >>> that
> >> >>> in my neighboring 2 buildings there are 3 people called Sagar Shah,
> >> >>> but
> >> >>> ofcourse with different dates of birth. Their addresses are also
> >> >>> different,
> >> >>> but simply a activityplan without the date of birth wouldn't have
> been
> >> >>> enough to identify the person.
> >> >>>
> >> >>>>
> >> >>>> OK.  Maybe I'm just getting twisted up between an ERM and an OO
> >> >>>> perspective.  From an OO perspective it might be clearer to have
> >> >>>> something like (excuse the minimalism):
> >> >>>>
> >> >>>>          +-------------+
> >> >>>>          | Person      |
> >> >>>>          |-------------|
> >> >>>>          | Names       |
> >> >>>>          | Addresses   |
> >> >>>>          | Identifiers |
> >> >>>>          +---+---------+
> >> >>>>              |
> >> >>>>              +----------+
> >> >>>>              |          |
> >> >>>>  +-----------+---+  +---+----------------+
> >> >>>>  |Client         |  |Provider            |
> >> >>>>  |---------------|  |--------------------|
> >> >>>>  |DOB            |  |Services delivered  |
> >> >>>>  |Sex            |  |                    |
> >> >>>>  |Cause of Death |  |                    |
> >> >>>>  |Services rcvd  |  |                    |
> >> >>>>  |etc            |  |                    |
> >> >>>>  +---------------+  +--------------------+
> >> >>>
> >> >>> The problem with classifying them separately is that, when the ANM
> is
> >> >>> pregnant, she has to get service from another ANM for ANC, PNC and
> >> >>> what have
> >> >>> you. Same is the case with a household. They may well be a Person
> >> >>> object
> >> >>> (which they are in the real-world) and based on the activityplan may
> >> >>> be
> >> >>> service provider or receiver (may be sometimes even simultaneously)
> >> >>> keeping
> >> >>> their "computer-world object" same... I have just tried to model
> these
> >> >>> objects based on what they would be in the real-life.
> >> >>> ---
> >> >>> 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
> >> >>>
> >> >>>
> >> >>>>
> >> >>>> I think this is a point of principle and not a technical decision -
> >> >>>> though clearly it has technical implications.  Most often there are
> >> >>>> also
> >> >>>> legal requirements.  In India for example, there is not yet a
> privacy
> >> >>>> of
> >> >>>> information act, but I have heard it is under discussion and we
> might
> >> >>>> yet see it in the next year.  It is interesting that, like South
> >> >>>> Africa,
> >> >>>> the demand for such legislation in India seems not to come from
> >> >>>> grassroots but rather from the requirements imposed by outsourcing
> to
> >> >>>> Europe where the requirements are much tighter.  So whereas
> >> >>>> privacy-fetishism could be seen as a peculiarly European thing, the
> >> >>>> proliferation of legislation might also be one of those
> >> >>>> "world-flattening" aspects of globalisation.  For better or worse.
> >> >>>>
> >> >>>> More often than not (discounting any moral drivers), security
> becomes
> >> >>>> about liability.  We need to be able to *show* that the systems we
> >> >>>> build
> >> >>>> take *reasonable* precautions to safeguard the integrity and access
> >> >>>> to
> >> >>>> data within the frameworks of existing legislation, regulation and
> >> >>>> good
> >> >>>> practice.  Otherwise we expose ourselves to risk.  Of course coders
> >> >>>> just
> >> >>>> want to code ...
> >> >>>>
> >> >>>> Regarding legislation (in the context of a global project) I think
> >> >>>> its
> >> >>>> best to assume that privacy requirements either exist or are likely
> >> >>>> on
> >> >>>> the horizon.  Regulations will always be a local matter of local
> >> >>>> public
> >> >>>> service regulations etc.  Good practice we can work on.  There is
> an
> >> >>>> ISO
> >> >>>> standard on health information system security which I've been
> >> >>>> meaning
> >> >>>> to get hold of.  And Calle made a very good point earlier that it
> was
> >> >>>> good practice regarding aggregate data to allow sharing with the
> >> >>>> minimum
> >> >>>> of restrictions.  We don't want to harm that.
> >> >>>>
> >> >>>> There are some other issues regarding difference between web and
> >> >>>> desktop
> >> >>>> applications and the best way to manage database connections.  On a
> >> >>>> server-based web-app it is most common to have a single
> authenticated
> >> >>>> connection between the app and the db. This is probably not best
> >> >>>> practice when the browser, the web app and the database are all
> >> >>>> together
> >> >>>> on one machine.  In this case I think its better to establish the
> >> >>>> connection at login time with the user providing the required
> >> >>>> authentication and using the database's mechanism.  If we maintain
> >> >>>> the
> >> >>>> current setup, where connections(s) are established via a
> >> >>>> hibernate.properties file for example, then we must still show that
> >> >>>> we
> >> >>>> have taken reasonable precautions for protecting access to the
> >> >>>> contents.
> >> >>>>
> >> >>>> All of which is doable.  Its a shame that Satvik left before we
> could
> >> >>>> setup the Risk Register.  That's a useful tool for this kind of
> thing
> >> >>>> -
> >> >>>> ie demonstrating that you have taken reasonable risks into account
> >> >>>> and
> >> >>>> taken reasonable precautions.
> >> >>>>
> >> >>>> Regards
> >> >>>> Bob
> >> >>>>
> >> >>>> >
> >> >>>> >
> >> >>>> >
> >> >>>> >         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
> >> >>>> >         >>>>>
>