dhis2-devs team mailing list archive

[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
>>> >         >>>>> >>>>>>>> > 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 ...
>>> >         >&
>>>
>>

Attachment: Class Diagram 1.png
Description: PNG image