dhis2-devs team mailing list archive
-
dhis2-devs team
-
Mailing list archive
-
Message #01251
Re: patient_dataelement Vs routine_dataelement
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 ...
>> > >>>>> >>>>>>>>
>> > >>>>> >>>>>>>> Cheers
>> > >>>>> >>>>>>>> Bob
>> > >>>>> >>>>>>>>
>> > >>>>> >>>>>>>> > Ola
>> > >>>>> >>>>>>>> > --------
>> > >>>>> >>>>>>>> >
>> > >>>>> >>>>>>>> >
>> > >>>>> >>>>>>>> >
>> > >>>>> >>>>>>>> >
>> > >>>>> >>>>>>>> >
>> > >>>>> >>>>>>>> >
>> > >>>>> >>>>>>>> >
>> > >>>>> >>>>>>>> >
>> > >>>>> >>>>>>>> >
>> > >>>>> >>>>>>>> >>
>> > >>>>> >>>>>>>> >> Regards
>> > >>>>> >>>>>>>> >> Bob
>> > >>>>> >>>>>>>> >>
>> > >>>>> >>>>>>>> >> > And we also talked about the need to
>> > extend the DataSet
>> > >>>>> >>>>>>>> >> > object
>> > >>>>> >>>>>>>> >> > to
>> > >>>>> >>>>>>>> >> > include
>> > >>>>> >>>>>>>> >> > more properties that makes datasets more
>> > flexible and
>> > >>>>> >>>>>>>> >> > dynamic
>> > >>>>> >>>>>>>> >> > as we need
>> > >>>>> >>>>>>>> >> > them for CIS and also for survey data.
>> > >>>>> >>>>>>>> >> >
>> > >>>>> >>>>>>>> >> > So here I guess we all agree, there is no
>> > need to come up
>> > >>>>> >>>>>>>> >> > with
>> > >>>>> >>>>>>>> >> > a
>> > >>>>> >>>>>>>> >> > separate
>> > >>>>> >>>>>>>> >> > PatientDataElement.
>> > >>>>> >>>>>>>> >> >
>> > >>>>> >>>>>>>> >> >
>> > >>&
>>
>
Attachment:
Class Diagram 1.png
Description: PNG image
Follow ups
References
-
patient_dataelement Vs routine_dataelement
From: Abyot Gizaw, 2009-06-03
-
Re: patient_dataelement Vs routine_dataelement
From: Bob Jolliffe, 2009-06-04
-
Re: patient_dataelement Vs routine_dataelement
From: Abyot Gizaw, 2009-06-04
-
Re: patient_dataelement Vs routine_dataelement
From: Ola Hodne Titlestad, 2009-06-04
-
Re: patient_dataelement Vs routine_dataelement
From: Abyot Gizaw, 2009-06-04
-
Re: patient_dataelement Vs routine_dataelement
From: Saptarshi Purkayastha, 2009-06-04
-
Re: patient_dataelement Vs routine_dataelement
From: Bob Jolliffe, 2009-06-05
-
Re: patient_dataelement Vs routine_dataelement
From: Saptarshi Purkayastha, 2009-06-06
-
Re: patient_dataelement Vs routine_dataelement
From: Bob Jolliffe, 2009-06-06
-
Re: patient_dataelement Vs routine_dataelement
From: Saptarshi Purkayastha, 2009-06-06
