patient_dataelement Vs routine_dataelement

Hi All,

Couldn’t really convince myself as to the need to keep a separate track of dataelements called patientdataelement. I just did an implementation for patientdataelement … but when giving it a thought about linking it with some custom and predefiend values, then I see that one already in place by Murod for the routine dataelements. And if we are going to have a case of like recording multiple values for a single patient dataelement, then we also will redo all the compex task of linking with options, categories and their combinations, which is again in place for the routine dataelements.

If the need to separate the two - routine and patient is only for the purpose of managment, then I think it will be better if we could introduce an attribute called ‘classification’ for dataelements. With this attribue we can classify our dataelements like - Routine, Patient, Header, Footer,…

Any input will be appreciated.

Thank you
Abyot.

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.

And we also talked about the need to extend the DataSet object to include more properties that makes datasets more flexible and dynamic as we need them for CIS and also for survey data.

So here I guess we all agree, there is no need to come up with a separate PatientDataElement.

best regards,
Ola Hodne Titlestad
HISP
University of Oslo

···

On Wed, Jun 3, 2009 at 11:26 AM, Abyot Gizaw abyota@gmail.com wrote:

Hi All,

Couldn’t really convince myself as to the need to keep a separate track of dataelements called patientdataelement. I just did an implementation for patientdataelement … but when giving it a thought about linking it with some custom and predefiend values, then I see that one already in place by Murod for the routine dataelements. And if we are going to have a case of like recording multiple values for a single patient dataelement, then we also will redo all the compex task of linking with options, categories and their combinations, which is again in place for the routine dataelements.

If the need to separate the two - routine and patient is only for the purpose of managment, then I think it will be better if we could introduce an attribute called ‘classification’ for dataelements. With this attribue we can classify our dataelements like - Routine, Patient, Header, Footer,…

Any input will be appreciated.

Thank you
Abyot.


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

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.
So I'm guessing Abyot will make a PatientDataElement with something
like a patientID.

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?

Regards
Bob

···

2009/6/3 Ola Hodne Titlestad <olati@ifi.uio.no>:

And we also talked about the need to extend the DataSet object to include
more properties that makes datasets more flexible and dynamic as we need
them for CIS and also for survey data.

So here I guess we all agree, there is no need to come up with a separate
PatientDataElement.

best regards,
Ola Hodne Titlestad
HISP
University of Oslo

On Wed, Jun 3, 2009 at 11:26 AM, Abyot Gizaw <abyota@gmail.com> wrote:

Hi All,

Couldn't really convince myself as to the need to keep a separate track of
dataelements called patientdataelement. I just did an implementation for
patientdataelement ... but when giving it a thought about linking it with
some custom and predefiend values, then I see that one already in place by
Murod for the routine dataelements. And if we are going to have a case of
like recording multiple values for a single patient dataelement, then we
also will redo all the compex task of linking with options, categories and
their combinations, which is again in place for the routine dataelements.

If the need to separate the two - routine and patient is only for the
purpose of managment, then I think it will be better if we could introduce
an attribute called 'classification' for dataelements. With this attribue we
can classify our dataelements like - Routine, Patient, Header, Footer,...

Any input will be appreciated.

Thank you
Abyot.

_______________________________________________
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp

_______________________________________________
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp

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.

Yes we agreed on the skype chat - but things do not fit smothly when it comes to actual coding. Actually I was looking into the document prepared by you. The number one task is “to represent patient data elements and add/edit GUI”

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.

Yes I agree. But, I think, this will not require us to have a specific dataelement different from what we have currently.

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.

Yes we have talked about that. That is not my question, I am not yet into this.

So here I guess we all agree, there is no need to come up with a separate PatientDataElement.

That is also my bet!! And I am planning to reuse as many objects as possible from the existing code.

But you didn’t comment on my suggestion - differentiating the dataelements using an attribute called “classification” and right now we have two classification. Routine and Patient. What do you think?

Thank you
Abyot.

···

On Wed, Jun 3, 2009 at 11:45 AM, Ola Hodne Titlestad olati@ifi.uio.no wrote:

best regards,
Ola Hodne Titlestad

HISP
University of Oslo

On Wed, Jun 3, 2009 at 11:26 AM, Abyot Gizaw abyota@gmail.com wrote:

Hi All,

Couldn’t really convince myself as to the need to keep a separate track of dataelements called patientdataelement. I just did an implementation for patientdataelement … but when giving it a thought about linking it with some custom and predefiend values, then I see that one already in place by Murod for the routine dataelements. And if we are going to have a case of like recording multiple values for a single patient dataelement, then we also will redo all the compex task of linking with options, categories and their combinations, which is again in place for the routine dataelements.

If the need to separate the two - routine and patient is only for the purpose of managment, then I think it will be better if we could introduce an attribute called ‘classification’ for dataelements. With this attribue we can classify our dataelements like - Routine, Patient, Header, Footer,…

Any input will be appreciated.

Thank you
Abyot.


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

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

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.

Ola

···

On Wed, Jun 3, 2009 at 12:04 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:

2009/6/3 Ola Hodne Titlestad olati@ifi.uio.no:


Regards

Bob

And we also talked about the need to extend the DataSet object to include

more properties that makes datasets more flexible and dynamic as we need

them for CIS and also for survey data.

So here I guess we all agree, there is no need to come up with a separate

PatientDataElement.

best regards,

Ola Hodne Titlestad

HISP

University of Oslo

On Wed, Jun 3, 2009 at 11:26 AM, Abyot Gizaw abyota@gmail.com wrote:

Hi All,

Couldn’t really convince myself as to the need to keep a separate track of

dataelements called patientdataelement. I just did an implementation for

patientdataelement … but when giving it a thought about linking it with

some custom and predefiend values, then I see that one already in place by

Murod for the routine dataelements. And if we are going to have a case of

like recording multiple values for a single patient dataelement, then we

also will redo all the compex task of linking with options, categories and

their combinations, which is again in place for the routine dataelements.

If the need to separate the two - routine and patient is only for the

purpose of managment, then I think it will be better if we could introduce

an attribute called ‘classification’ for dataelements. With this attribue we

can classify our dataelements like - Routine, Patient, Header, Footer,…

Any input will be appreciated.

Thank you

Abyot.


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

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.

Yes we agreed on the skype chat - but things do not fit smothly when it comes to actual coding. Actually I was looking into the document prepared by you. The number one task is “to represent patient data elements and add/edit GUI”

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.

Yes I agree. But, I think, this will not require us to have a specific dataelement different from what we have currently.

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.

Yes we have talked about that. That is not my question, I am not yet into this.

So here I guess we all agree, there is no need to come up with a separate PatientDataElement.

That is also my bet!! And I am planning to reuse as many objects as possible from the existing code.

But you didn’t comment on my suggestion - differentiating the dataelements using an attribute called “classification” and right now we have two classification. Routine and Patient. What do you think?

I thin this separation should not be in the data element, which we should keep as generic as possible, but in the dataset, where we say something about HOW a data element will be used. In a typical CHIS scenario you would use the same data element for both client and routine data, since client is conceptually just an extension of the orgunit, and the data we register are the same whether it is from a daily client register or the monthly aggregated report. Exactly how we can support this duality of data elements I am not sure… would it be enough to keep that separation in dataset (says soemthing about who you register for and how often) and data value (says who the data belongs to and for what period)? I hope so.

···

On Wed, Jun 3, 2009 at 12:06 PM, Abyot Gizaw abyota@gmail.com wrote:

On Wed, Jun 3, 2009 at 11:45 AM, Ola Hodne Titlestad olati@ifi.uio.no wrote:

Thank you
Abyot.

best regards,
Ola Hodne Titlestad

HISP
University of Oslo

On Wed, Jun 3, 2009 at 11:26 AM, Abyot Gizaw abyota@gmail.com wrote:

Hi All,

Couldn’t really convince myself as to the need to keep a separate track of dataelements called patientdataelement. I just did an implementation for patientdataelement … but when giving it a thought about linking it with some custom and predefiend values, then I see that one already in place by Murod for the routine dataelements. And if we are going to have a case of like recording multiple values for a single patient dataelement, then we also will redo all the compex task of linking with options, categories and their combinations, which is again in place for the routine dataelements.

If the need to separate the two - routine and patient is only for the purpose of managment, then I think it will be better if we could introduce an attribute called ‘classification’ for dataelements. With this attribue we can classify our dataelements like - Routine, Patient, Header, Footer,…

Any input will be appreciated.

Thank you
Abyot.


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

> 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

···

2009/6/3 Ola Hodne Titlestad <olati@ifi.uio.no>:

On Wed, Jun 3, 2009 at 12:04 PM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

2009/6/3 Ola Hodne Titlestad <olati@ifi.uio.no>:

Ola
--------

Regards
Bob

> And we also talked about the need to extend the DataSet object to
> include
> more properties that makes datasets more flexible and dynamic as we need
> them for CIS and also for survey data.
>
> So here I guess we all agree, there is no need to come up with a
> separate
> PatientDataElement.
>
>
> best regards,
> Ola Hodne Titlestad
> HISP
> University of Oslo
>
>
> On Wed, Jun 3, 2009 at 11:26 AM, Abyot Gizaw <abyota@gmail.com> wrote:
>>
>> Hi All,
>>
>> Couldn't really convince myself as to the need to keep a separate track
>> of
>> dataelements called patientdataelement. I just did an implementation
>> for
>> patientdataelement ... but when giving it a thought about linking it
>> with
>> some custom and predefiend values, then I see that one already in place
>> by
>> Murod for the routine dataelements. And if we are going to have a case
>> of
>> like recording multiple values for a single patient dataelement, then
>> we
>> also will redo all the compex task of linking with options, categories
>> and
>> their combinations, which is again in place for the routine
>> dataelements.
>>
>> If the need to separate the two - routine and patient is only for the
>> purpose of managment, then I think it will be better if we could
>> introduce
>> an attribute called 'classification' for dataelements. With this
>> attribue we
>> can classify our dataelements like - Routine, Patient, Header,
>> Footer,...
>>
>> Any input will be appreciated.
>>
>> Thank you
>> Abyot.
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~dhis2-devs
>> Post to : dhis2-devs@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~dhis2-devs
>> More help : https://help.launchpad.net/ListHelp
>>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to : dhis2-devs@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help : https://help.launchpad.net/ListHelp
>
>

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.

¡P DataSet

o Source

o Period (for CHIS, daily periodType)

o set

¡P ActivityPlan

o Owner – person (Health Extension Worker)

o Supervisor – person (Medical Officer)

o Date – date

o Activities – set

¡P 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 (list of data to be collected)

¡P 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@gmail.com wrote:

2009/6/3 Ola Hodne Titlestad olati@ifi.uio.no:

On Wed, Jun 3, 2009 at 12:04 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:

2009/6/3 Ola Hodne Titlestad olati@ifi.uio.no:

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
  1. 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:

<dataset name="header" >

   <dataelement name="????" >

         <datavalue source="[clinicID]" period="???" value="34" />

   </dataelement>

   <dataelement name="????" >

         <datavalue source="[clinicID]" period="???" value="34" />

   </dataelement>

</dataset>
    <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>

While typing the above it occurred to me that header AND footer are

probably not necessary for representing a register. What we really

need is a set of dataelements associated with the register and a set

associated with register rows. Whether the elements in the former are

eventually rendered in the header or the footer is probably a

presentation issue which could be determined by, for example, the name

or ID of the dataelement.

Also the above patientdataset is grouped on the dataelement axis.

Could also be grouped on source/patientID, making it closer in analogy

to rows in a register. Though deriving the latter from the former is

a simple enough transformation.

Abyot, returning to your original question, I don’t know if having a

dataelement classification is necessary. If the dataelements are

always members of a dataset (at least one or only one …) then

probably not. But I think you are right that it is only as you hammer

out the detail that the truth might emerge …

Cheers

Bob

Ola


Regards

Bob

And we also talked about the need to extend the DataSet object to

include

more properties that makes datasets more flexible and dynamic as we need

them for CIS and also for survey data.

So here I guess we all agree, there is no need to come up with a

separate

PatientDataElement.

best regards,

Ola Hodne Titlestad

HISP

University of Oslo

On Wed, Jun 3, 2009 at 11:26 AM, Abyot Gizaw abyota@gmail.com wrote:

Hi All,

Couldn’t really convince myself as to the need to keep a separate track

of

dataelements called patientdataelement. I just did an implementation

for

patientdataelement … but when giving it a thought about linking it

with

some custom and predefiend values, then I see that one already in place

by

Murod for the routine dataelements. And if we are going to have a case

of

like recording multiple values for a single patient dataelement, then

we

also will redo all the compex task of linking with options, categories

and

their combinations, which is again in place for the routine

dataelements.

If the need to separate the two - routine and patient is only for the

purpose of managment, then I think it will be better if we could

introduce

an attribute called ‘classification’ for dataelements. With this

attribue we

can classify our dataelements like - Routine, Patient, Header,

Footer,…

Any input will be appreciated.

Thank you

Abyot.


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

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.

¡P DataSet

o Source

o Period (for CHIS, daily periodType)

o set

¡P ActivityPlan

o Owner – person (Health Extension Worker)

o Supervisor – person (Medical Officer)

o Date – date

o Activities – set

¡P 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 (list of data to be collected)

Sorry for the above strange stuff. I think it is better like down below.

¡P Encounter

o DataSet

o ByWhom – person (the patient)

o When – date (time stamp)

···

2009/6/3 Abyot Gizaw abyota@gmail.com

¡P 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@gmail.com wrote:

2009/6/3 Ola Hodne Titlestad olati@ifi.uio.no:

On Wed, Jun 3, 2009 at 12:04 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:

2009/6/3 Ola Hodne Titlestad olati@ifi.uio.no:

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
  1. 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:

<dataset name="header" >

   <dataelement name="????" >

         <datavalue source="[clinicID]" period="???" value="34" />

   </dataelement>

   <dataelement name="????" >

         <datavalue source="[clinicID]" period="???" value="34" />

   </dataelement>

</dataset>
    <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>

While typing the above it occurred to me that header AND footer are

probably not necessary for representing a register. What we really

need is a set of dataelements associated with the register and a set

associated with register rows. Whether the elements in the former are

eventually rendered in the header or the footer is probably a

presentation issue which could be determined by, for example, the name

or ID of the dataelement.

Also the above patientdataset is grouped on the dataelement axis.

Could also be grouped on source/patientID, making it closer in analogy

to rows in a register. Though deriving the latter from the former is

a simple enough transformation.

Abyot, returning to your original question, I don’t know if having a

dataelement classification is necessary. If the dataelements are

always members of a dataset (at least one or only one …) then

probably not. But I think you are right that it is only as you hammer

out the detail that the truth might emerge …

Cheers

Bob

Ola


Regards

Bob

And we also talked about the need to extend the DataSet object to

include

more properties that makes datasets more flexible and dynamic as we need

them for CIS and also for survey data.

So here I guess we all agree, there is no need to come up with a

separate

PatientDataElement.

best regards,

Ola Hodne Titlestad

HISP

University of Oslo

On Wed, Jun 3, 2009 at 11:26 AM, Abyot Gizaw abyota@gmail.com wrote:

Hi All,

Couldn’t really convince myself as to the need to keep a separate track

of

dataelements called patientdataelement. I just did an implementation

for

patientdataelement … but when giving it a thought about linking it

with

some custom and predefiend values, then I see that one already in place

by

Murod for the routine dataelements. And if we are going to have a case

of

like recording multiple values for a single patient dataelement, then

we

also will redo all the compex task of linking with options, categories

and

their combinations, which is again in place for the routine

dataelements.

If the need to separate the two - routine and patient is only for the

purpose of managment, then I think it will be better if we could

introduce

an attribute called ‘classification’ for dataelements. With this

attribue we

can classify our dataelements like - Routine, Patient, Header,

Footer,…

Any input will be appreciated.

Thank you

Abyot.


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

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@gmail.com

2009/6/3 Abyot Gizaw abyota@gmail.com

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

· ActivityPlan

o Owner – person (Health Extension Worker)

o Supervisor – person (Medical Officer)

o Date – date

o Activities – set

· 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 (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@gmail.com wrote:

2009/6/3 Ola Hodne Titlestad olati@ifi.uio.no:

On Wed, Jun 3, 2009 at 12:04 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:

2009/6/3 Ola Hodne Titlestad olati@ifi.uio.no:

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
  1. 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:

<dataset name="header" >

   <dataelement name="????" >

         <datavalue source="[clinicID]" period="???" value="34" />

   </dataelement>

   <dataelement name="????" >

         <datavalue source="[clinicID]" period="???" value="34" />

   </dataelement>

</dataset>
    <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>

While typing the above it occurred to me that header AND footer are

probably not necessary for representing a register. What we really

need is a set of dataelements associated with the register and a set

associated with register rows. Whether the elements in the former are

eventually rendered in the header or the footer is probably a

presentation issue which could be determined by, for example, the name

or ID of the dataelement.

Also the above patientdataset is grouped on the dataelement axis.

Could also be grouped on source/patientID, making it closer in analogy

to rows in a register. Though deriving the latter from the former is

a simple enough transformation.

Abyot, returning to your original question, I don’t know if having a

dataelement classification is necessary. If the dataelements are

always members of a dataset (at least one or only one …) then

probably not. But I think you are right that it is only as you hammer

out the detail that the truth might emerge …

Cheers

Bob

Ola


Regards

Bob

And we also talked about the need to extend the DataSet object to

include

more properties that makes datasets more flexible and dynamic as we need

them for CIS and also for survey data.

So here I guess we all agree, there is no need to come up with a

separate

PatientDataElement.

best regards,

Ola Hodne Titlestad

HISP

University of Oslo

On Wed, Jun 3, 2009 at 11:26 AM, Abyot Gizaw abyota@gmail.com wrote:

Hi All,

Couldn’t really convince myself as to the need to keep a separate track

of

dataelements called patientdataelement. I just did an implementation

for

patientdataelement … but when giving it a thought about linking it

with

some custom and predefiend values, then I see that one already in place

by

Murod for the routine dataelements. And if we are going to have a case

of

like recording multiple values for a single patient dataelement, then

we

also will redo all the compex task of linking with options, categories

and

their combinations, which is again in place for the routine

dataelements.

If the need to separate the two - routine and patient is only for the

purpose of managment, then I think it will be better if we could

introduce

an attribute called ‘classification’ for dataelements. With this

attribue we

can classify our dataelements like - Routine, Patient, Header,

Footer,…

Any input will be appreciated.

Thank you

Abyot.


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

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.

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.

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.

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.

Thanks
Abyot.

···

2009/6/3 Ola Hodne Titlestad olati@ifi.uio.no

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@gmail.com

2009/6/3 Abyot Gizaw abyota@gmail.com

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

· ActivityPlan

o Owner – person (Health Extension Worker)

o Supervisor – person (Medical Officer)

o Date – date

o Activities – set

· 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 (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@gmail.com wrote:

2009/6/3 Ola Hodne Titlestad olati@ifi.uio.no:

On Wed, Jun 3, 2009 at 12:04 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:

2009/6/3 Ola Hodne Titlestad olati@ifi.uio.no:

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
  1. 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:

<dataset name="header" >

   <dataelement name="????" >

         <datavalue source="[clinicID]" period="???" value="34" />

   </dataelement>

   <dataelement name="????" >

         <datavalue source="[clinicID]" period="???" value="34" />

   </dataelement>

</dataset>
    <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>

While typing the above it occurred to me that header AND footer are

probably not necessary for representing a register. What we really

need is a set of dataelements associated with the register and a set

associated with register rows. Whether the elements in the former are

eventually rendered in the header or the footer is probably a

presentation issue which could be determined by, for example, the name

or ID of the dataelement.

Also the above patientdataset is grouped on the dataelement axis.

Could also be grouped on source/patientID, making it closer in analogy

to rows in a register. Though deriving the latter from the former is

a simple enough transformation.

Abyot, returning to your original question, I don’t know if having a

dataelement classification is necessary. If the dataelements are

always members of a dataset (at least one or only one …) then

probably not. But I think you are right that it is only as you hammer

out the detail that the truth might emerge …

Cheers

Bob

Ola


Regards

Bob

And we also talked about the need to extend the DataSet object to

include

more properties that makes datasets more flexible and dynamic as we need

them for CIS and also for survey data.

So here I guess we all agree, there is no need to come up with a

separate

PatientDataElement.

best regards,

Ola Hodne Titlestad

HISP

University of Oslo

On Wed, Jun 3, 2009 at 11:26 AM, Abyot Gizaw abyota@gmail.com wrote:

Hi All,

Couldn’t really convince myself as to the need to keep a separate track

of

dataelements called patientdataelement. I just did an implementation

for

patientdataelement … but when giving it a thought about linking it

with

some custom and predefiend values, then I see that one already in place

by

Murod for the routine dataelements. And if we are going to have a case

of

like recording multiple values for a single patient dataelement, then

we

also will redo all the compex task of linking with options, categories

and

their combinations, which is again in place for the routine

dataelements.

If the need to separate the two - routine and patient is only for the

purpose of managment, then I think it will be better if we could

introduce

an attribute called ‘classification’ for dataelements. With this

attribue we

can classify our dataelements like - Routine, Patient, Header,

Footer,…

Any input will be appreciated.

Thank you

Abyot.


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

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

···

2009/6/3 Abyot Gizaw abyota@gmail.com

Thanks
Abyot.

2009/6/3 Ola Hodne Titlestad olati@ifi.uio.no

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@gmail.com

2009/6/3 Abyot Gizaw abyota@gmail.com

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

· ActivityPlan

o Owner – person (Health Extension Worker)

o Supervisor – person (Medical Officer)

o Date – date

o Activities – set

· 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 (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@gmail.com wrote:

2009/6/3 Ola Hodne Titlestad olati@ifi.uio.no:

On Wed, Jun 3, 2009 at 12:04 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:

2009/6/3 Ola Hodne Titlestad olati@ifi.uio.no:

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
  1. 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:

<dataset name="header" >

   <dataelement name="????" >

         <datavalue source="[clinicID]" period="???" value="34" />

   </dataelement>

   <dataelement name="????" >

         <datavalue source="[clinicID]" period="???" value="34" />

   </dataelement>

</dataset>
    <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>

While typing the above it occurred to me that header AND footer are

probably not necessary for representing a register. What we really

need is a set of dataelements associated with the register and a set

associated with register rows. Whether the elements in the former are

eventually rendered in the header or the footer is probably a

presentation issue which could be determined by, for example, the name

or ID of the dataelement.

Also the above patientdataset is grouped on the dataelement axis.

Could also be grouped on source/patientID, making it closer in analogy

to rows in a register. Though deriving the latter from the former is

a simple enough transformation.

Abyot, returning to your original question, I don’t know if having a

dataelement classification is necessary. If the dataelements are

always members of a dataset (at least one or only one …) then

probably not. But I think you are right that it is only as you hammer

out the detail that the truth might emerge …

Cheers

Bob

Ola


Regards

Bob

And we also talked about the need to extend the DataSet object to

include

more properties that makes datasets more flexible and dynamic as we need

them for CIS and also for survey data.

So here I guess we all agree, there is no need to come up with a

separate

PatientDataElement.

best regards,

Ola Hodne Titlestad

HISP

University of Oslo

On Wed, Jun 3, 2009 at 11:26 AM, Abyot Gizaw abyota@gmail.com wrote:

Hi All,

Couldn’t really convince myself as to the need to keep a separate track

of

dataelements called patientdataelement. I just did an implementation

for

patientdataelement … but when giving it a thought about linking it

with

some custom and predefiend values, then I see that one already in place

by

Murod for the routine dataelements. And if we are going to have a case

of

like recording multiple values for a single patient dataelement, then

we

also will redo all the compex task of linking with options, categories

and

their combinations, which is again in place for the routine

dataelements.

If the need to separate the two - routine and patient is only for the

purpose of managment, then I think it will be better if we could

introduce

an attribute called ‘classification’ for dataelements. With this

attribue we

can classify our dataelements like - Routine, Patient, Header,

Footer,…

Any input will be appreciated.

Thank you

Abyot.


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

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@ifi.uio.no

2009/6/3 Abyot Gizaw abyota@gmail.com

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@ifi.uio.no

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@gmail.com

2009/6/3 Abyot Gizaw abyota@gmail.com

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

· ActivityPlan

o Owner – person (Health Extension Worker)

o Supervisor – person (Medical Officer)

o Date – date

o Activities – set

· 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 (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@gmail.com wrote:

2009/6/3 Ola Hodne Titlestad olati@ifi.uio.no:

On Wed, Jun 3, 2009 at 12:04 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:

2009/6/3 Ola Hodne Titlestad olati@ifi.uio.no:

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
  1. 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:

<dataset name="header" >

   <dataelement name="????" >

         <datavalue source="[clinicID]" period="???" value="34" />

   </dataelement>

   <dataelement name="????" >

         <datavalue source="[clinicID]" period="???" value="34" />

   </dataelement>

</dataset>
    <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>

While typing the above it occurred to me that header AND footer are

probably not necessary for representing a register. What we really

need is a set of dataelements associated with the register and a set

associated with register rows. Whether the elements in the former are

eventually rendered in the header or the footer is probably a

presentation issue which could be determined by, for example, the name

or ID of the dataelement.

Also the above patientdataset is grouped on the dataelement axis.

Could also be grouped on source/patientID, making it closer in analogy

to rows in a register. Though deriving the latter from the former is

a simple enough transformation.

Abyot, returning to your original question, I don’t know if having a

dataelement classification is necessary. If the dataelements are

always members of a dataset (at least one or only one …) then

probably not. But I think you are right that it is only as you hammer

out the detail that the truth might emerge …

Cheers

Bob

Ola


Regards

Bob

And we also talked about the need to extend the DataSet object to

include

more properties that makes datasets more flexible and dynamic as we need

them for CIS and also for survey data.

So here I guess we all agree, there is no need to come up with a

separate

PatientDataElement.

best regards,

Ola Hodne Titlestad

HISP

University of Oslo

On Wed, Jun 3, 2009 at 11:26 AM, Abyot Gizaw abyota@gmail.com wrote:

Hi All,

Couldn’t really convince myself as to the need to keep a separate track

of

dataelements called patientdataelement. I just did an implementation

for

patientdataelement … but when giving it a thought about linking it

with

some custom and predefiend values, then I see that one already in place

by

Murod for the routine dataelements. And if we are going to have a case

of

like recording multiple values for a single patient dataelement, then

we

also will redo all the compex task of linking with options, categories

and

their combinations, which is again in place for the routine

dataelements.

If the need to separate the two - routine and patient is only for the

purpose of managment, then I think it will be better if we could

introduce

an attribute called ‘classification’ for dataelements. With this

attribue we

can classify our dataelements like - Routine, Patient, Header,

Footer,…

Any input will be appreciated.

Thank you

Abyot.


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

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”.

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

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@gmail.com

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@ifi.uio.no

2009/6/3 Abyot Gizaw abyota@gmail.com

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@ifi.uio.no

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@gmail.com

2009/6/3 Abyot Gizaw abyota@gmail.com

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

· ActivityPlan

o Owner – person (Health Extension Worker)

o Supervisor – person (Medical Officer)

o Date – date

o Activities – set

· 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 (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@gmail.com wrote:

2009/6/3 Ola Hodne Titlestad olati@ifi.uio.no:

On Wed, Jun 3, 2009 at 12:04 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:

2009/6/3 Ola Hodne Titlestad olati@ifi.uio.no:

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
  1. 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:

<dataset name="header" >

   <dataelement name="????" >

         <datavalue source="[clinicID]" period="???" value="34" />

   </dataelement>

   <dataelement name="????" >

         <datavalue source="[clinicID]" period="???" value="34" />

   </dataelement>

</dataset>
    <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>

While typing the above it occurred to me that header AND footer are

probably not necessary for representing a register. What we really

need is a set of dataelements associated with the register and a set

associated with register rows. Whether the elements in the former are

eventually rendered in the header or the footer is probably a

presentation issue which could be determined by, for example, the name

or ID of the dataelement.

Also the above patientdataset is grouped on the dataelement axis.

Could also be grouped on source/patientID, making it closer in analogy

to rows in a register. Though deriving the latter from the former is

a simple enough transformation.

Abyot, returning to your original question, I don’t know if having a

dataelement classification is necessary. If the dataelements are

always members of a dataset (at least one or only one …) then

probably not. But I think you are right that it is only as you hammer

out the detail that the truth might emerge …

Cheers

Bob

Ola


Regards

Bob

And we also talked about the need to extend the DataSet object to

include

more properties that makes datasets more flexible and dynamic as we need

them for CIS and also for survey data.

So here I guess we all agree, there is no need to come up with a

separate

PatientDataElement.

best regards,

Ola Hodne Titlestad

HISP

University of Oslo

On Wed, Jun 3, 2009 at 11:26 AM, Abyot Gizaw abyota@gmail.com wrote:

Hi All,

Couldn’t really convince myself as to the need to keep a separate track

of

dataelements called patientdataelement. I just did an implementation

for

patientdataelement … but when giving it a thought about linking it

with

some custom and predefiend values, then I see that one already in place

by

Murod for the routine dataelements. And if we are going to have a case

of

like recording multiple values for a single patient dataelement, then

we

also will redo all the compex task of linking with options, categories

and

their combinations, which is again in place for the routine

dataelements.

If the need to separate the two - routine and patient is only for the

purpose of managment, then I think it will be better if we could

introduce

an attribute called ‘classification’ for dataelements. With this

attribue we

can classify our dataelements like - Routine, Patient, Header,

Footer,…

Any input will be appreciated.

Thank you

Abyot.


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

I too have been silently following the discussion, understanding
little about what has been discussed, and having a number of
trepidations about what was discussed. I was unfortunately not able to
join the Skype conference last week, as I was out in the field and had
not internet access. I wish I could have been there.

Anyway, I could not agree with Saptarshi more. The various discussions
need to be distilled down into a diagram as soon as possible. I have
some different ideas about how such a module (or what it seems to be
morphing into a separate application) should work, based on
requirements that have been expressed here in Zambia, which seem to be
very different from the discussion that I have been following over the
past few weeks.

Could we maybe setup something on Launchpad to allow this to start happening?

Regards,
Jason

···

2009/6/4 Saptarshi Purkayastha <sunbiz@gmail.com>:

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".
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. 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.
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@gmail.com>

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@ifi.uio.no>

2009/6/3 Abyot Gizaw <abyota@gmail.com>

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@ifi.uio.no>

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@gmail.com>

2009/6/3 Abyot Gizaw <abyota@gmail.com>

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@gmail.com> >>>>>>> wrote:

2009/6/3 Ola Hodne Titlestad <olati@ifi.uio.no>:
> On Wed, Jun 3, 2009 at 12:04 PM, Bob Jolliffe >>>>>>>> > <bobjolliffe@gmail.com> wrote:
>>
>> 2009/6/3 Ola Hodne Titlestad <olati@ifi.uio.no>:
>> > Hi Abyot,
>> >
>> > If you read my summary e-mails just before the skype conference
>> > you will
>> > see
>> > that my suggestion was NOT to have a different type of data
>> > element, and
>> > I
>> > understood from the skype chat that we agreed on the same. What
>> > we
>> > talked
>> > about was to possibly make a separation in the user interface
>> > to avoid
>> > confusing the users, but in the background use the same
>> > DataElement
>> > object,
>> > but I am not sure that will always be needed as there are lot
>> > of overlap
>> > between routine and CHIS data elements.
>> >
>> > As you say, if we want to easily reuse datasets and data entry
>> > forms
>> > functionality we need to use the DataElement object also for
>> > client data
>> > elements. And of course we want to reuse what Murid has
>> > implemented
>> > regarding option lists for pre-defined values for data
>> > elements.
>> >
>> > The separation comes in DataValue as the PatientDataValue will
>> > need
>> > other
>> > properties than the (routine) DataValue.
>>
>> Agreed. But what would these properties be exactly? Two options
>> which have surfaced are:
>> 1. an additional patientID attribute; or
>> 2. no additional attribute - association of patient as a "source"
>>
>> The first is most obvious and perhaps simplest. And I suspect I
>> am
>> the only one crazy enough to see any merit in exploring the
>> second.
>
> patientID yes, but probably also a DataSetID as we need to keep
> track (and
> separation) of the encounters/visits (instances of a dataset, "a
> filled
> form") in a more efficient way than we do in DataValue now.
> At least this is how its done in 1.4 Patient module and also for
> Survey type
> data.
>
>
>>
>> So I'm guessing Abyot will make a PatientDataElement with
>> something
>> like a patientID.
>
> Data elements do not have any direct reference to its source, so
> this should
> not be necessary. It is the datavalue that keeps this reference
> and which
> again is controlled by the dataset.

Sorry typo - I meant PatientDataValue ..

> We would in stead need a maintain Patients/Clients in a separate
> object, and
> pherhaps in a hierarchy (family, village). Lars also liked the
> idea of
> implementing the source object here, and I am open to that. After
> all that
> is why we created the source, to have diffeent types of sources to
> register
> data, not only orgunits.
> The peirod handling might also be different here as we always work
> on dates
> since these data are snapshots in time and not aggregtated over a
> certain
> period.
>
> Calle might have some useful input to how patient values are
> different from
> routine, apart from the security aspect we already discussed some
> weeks
> back.
>
>>
>> What else? Do we need a concept like an encounter (or visit) to
>> which
>> a date would be tied? Or can something be done with a
>> PeriodType?
>
> If we are going to reuse the DHIS concepts of data element,
> dataset, data
> entry form and data value then the dataset is the key here.
> In many ways routine datasets and "client" datasets are very
> similar, and "a
> filled form", or what might be called an instance of a dataset,
> contains
> values linked to data elements for a given period and a given
> source. Client
> encounters, rows from a register book, are also like that; a
> client name,
> multiple data elements (columns in the book) with values, and a
> date. After
> all its the final row of the register book, the total row
> aggregating all
> the encounters that gives the routine values for a monthly routine
> dataset.
> This example also illustrates how data elements overlap between
> client data
> and routine data, routine data are simply the total of "all
> clients" for the
> month. (This is not the case in survey audit type of datasets e.g.
> with
> maternal detah audits, but for standard CHIS it is mostly the
> case)
>
> If we keep track of the DatasetID in a ClientDataValue object we
> can the
> easily get an ecounter by querying for a client + a date + a
> dataset, or a
> list of all encounters (within a certain programme (dataset)) by
> querying
> for a client + a dataset. Of course it would be possible to get
> all data
> elements belonging to a dataset without directly referencing
> datasetid in
> datavalue, we do that today for dataset reports. Again, we need to
> check
> this with Calle or others, but I think client data are different
> in the way
> that a data element can exist in multiple datasets AND be
> registered for all
> of them for the same client and date, because the same data
> elements in
> different datasets might have different meanings and values. For
> routine
> this is not the case, that is why we di not keep a reference to
> dataset in
> datavalue, it is enough to use data element to describe the
> meaning of the
> data.
>
> So each encounter will be a data entry form, and its metadata will
> be
> controlled through the dataset object, similar to how its done for
> routine
> data. In the dataset object we need to specify what kind of data
> that is
> going to be registered,e.g. aggregated, disaggregated, survey(or
> routine,
> client, survey). Semi-permanent is then included in routine which
> is a bit
> confusing, that is why I prefer aggregated. Anyway, the principle
> is the
> same.

OK. This makes sense. A register object (for want of a better
term)
would be a specialisation of dataset.

> Datasets could be made even more dynamic, as we discussed on
> Skype, by
> adding other attributes like a set of header data elements and a
> set of
> footer data elements. These will be based on the same type of data
> elements,
> but stored or treated in a different way (in data entry and data
> value).Exactly how I am not sure, but we should look in detail at
> how 1.4
> treats header data elements.

Trying to piece together what a register might look like in xml:

<register name="Immunization register">
<dataset name="header" >
<dataelement name="???" >
<datavalue source="[clinicID]" period="???" value="34"
/>
</dataelement>
<dataelement name="???" >
<datavalue source="[clinicID]" period="???" value="34"
/>
</dataelement>
</dataset>

<patientdataset name="immunization data" />
<dataelement name="???">
<patientdatavalue source="[patientID1]" value="36"
date="01/01/2010" /> <!-- should date be done with a period type?
<patientdatavalue source="[patientID2]" value="43"
date="01/01/2010" />
<patientdatavalue source="[patientID3]" value="35"
date="01/01/2010" />
<patientdatavalue source="[patientID4]" value="22"
date="01/01/2010" />
</dataelement>
<dataelement name="???">
<patientdatavalue source="[patientID1]" value="36"
date="01/01/2010" />
<patientdatavalue source="[patientID2]" value="43"
date="01/01/2010" />
<patientdatavalue source="[patientID3]" value="35"
date="01/01/2010" />
<patientdatavalue source="[patientID4]" value="22"
date="01/01/2010" />
</dataelement>
</patientdataelement>

</register>

While typing the above it occurred to me that header AND footer are
probably not necessary for representing a register. What we really
need is a set of dataelements associated with the register and a set
associated with register rows. Whether the elements in the former
are
eventually rendered in the header or the footer is probably a
presentation issue which could be determined by, for example, the
name
or ID of the dataelement.

Also the above patientdataset is grouped on the dataelement axis.
Could also be grouped on source/patientID, making it closer in
analogy
to rows in a register. Though deriving the latter from the former
is
a simple enough transformation.

Abyot, returning to your original question, I don't know if having a
dataelement classification is necessary. If the dataelements are
always members of a dataset (at least one or only one ..) then
probably not. But I think you are right that it is only as you
hammer
out the detail that the truth might emerge ...

Cheers
Bob

> Ola
> --------
>
>
>
>
>
>
>
>
>
>>
>> Regards
>> Bob
>>
>> > And we also talked about the need to extend the DataSet object
>> > to
>> > include
>> > more properties that makes datasets more flexible and dynamic
>> > as we need
>> > them for CIS and also for survey data.
>> >
>> > So here I guess we all agree, there is no need to come up with
>> > a
>> > separate
>> > PatientDataElement.
>> >
>> >
>> > best regards,
>> > Ola Hodne Titlestad
>> > HISP
>> > University of Oslo
>> >
>> >
>> > On Wed, Jun 3, 2009 at 11:26 AM, Abyot Gizaw <abyota@gmail.com> >>>>>>>> >> > wrote:
>> >>
>> >> Hi All,
>> >>
>> >> Couldn't really convince myself as to the need to keep a
>> >> separate track
>> >> of
>> >> dataelements called patientdataelement. I just did an
>> >> implementation
>> >> for
>> >> patientdataelement ... but when giving it a thought about
>> >> linking it
>> >> with
>> >> some custom and predefiend values, then I see that one already
>> >> in place
>> >> by
>> >> Murod for the routine dataelements. And if we are going to
>> >> have a case
>> >> of
>> >> like recording multiple values for a single patient
>> >> dataelement, then
>> >> we
>> >> also will redo all the compex task of linking with options,
>> >> categories
>> >> and
>> >> their combinations, which is again in place for the routine
>> >> dataelements.
>> >>
>> >> If the need to separate the two - routine and patient is only
>> >> for the
>> >> purpose of managment, then I think it will be better if we
>> >> could
>> >> introduce
>> >> an attribute called 'classification' for dataelements. With
>> >> this
>> >> attribue we
>> >> can classify our dataelements like - Routine, Patient, Header,
>> >> Footer,...
>> >>
>> >> Any input will be appreciated.
>> >>
>> >> Thank you
>> >> Abyot.
>> >>
>> >> _______________________________________________
>> >> Mailing list: https://launchpad.net/~dhis2-devs
>> >> Post to : dhis2-devs@lists.launchpad.net
>> >> Unsubscribe : https://launchpad.net/~dhis2-devs
>> >> More help : https://help.launchpad.net/ListHelp
>> >>
>> >
>> >
>> > _______________________________________________
>> > Mailing list: https://launchpad.net/~dhis2-devs
>> > Post to : dhis2-devs@lists.launchpad.net
>> > Unsubscribe : https://launchpad.net/~dhis2-devs
>> > More help : https://help.launchpad.net/ListHelp
>> >
>> >
>
>

_______________________________________________
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp

_______________________________________________
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp

Hi

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

···

2009/6/4 Saptarshi Purkayastha <sunbiz@gmail.com>:

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@gmail.com>

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@ifi.uio.no>

2009/6/3 Abyot Gizaw <abyota@gmail.com>

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@ifi.uio.no>

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@gmail.com>

2009/6/3 Abyot Gizaw <abyota@gmail.com>

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@gmail.com> >>>>>>> wrote:

2009/6/3 Ola Hodne Titlestad <olati@ifi.uio.no>:
> On Wed, Jun 3, 2009 at 12:04 PM, Bob Jolliffe >>>>>>>> > <bobjolliffe@gmail.com> wrote:
>>
>> 2009/6/3 Ola Hodne Titlestad <olati@ifi.uio.no>:
>> > Hi Abyot,
>> >
>> > If you read my summary e-mails just before the skype conference
>> > you will
>> > see
>> > that my suggestion was NOT to have a different type of data
>> > element, and
>> > I
>> > understood from the skype chat that we agreed on the same. What
>> > we
>> > talked
>> > about was to possibly make a separation in the user interface
>> > to avoid
>> > confusing the users, but in the background use the same
>> > DataElement
>> > object,
>> > but I am not sure that will always be needed as there are lot
>> > of overlap
>> > between routine and CHIS data elements.
>> >
>> > As you say, if we want to easily reuse datasets and data entry
>> > forms
>> > functionality we need to use the DataElement object also for
>> > client data
>> > elements. And of course we want to reuse what Murid has
>> > implemented
>> > regarding option lists for pre-defined values for data
>> > elements.
>> >
>> > The separation comes in DataValue as the PatientDataValue will
>> > need
>> > other
>> > properties than the (routine) DataValue.
>>
>> Agreed. But what would these properties be exactly? Two options
>> which have surfaced are:
>> 1. an additional patientID attribute; or
>> 2. no additional attribute - association of patient as a "source"
>>
>> The first is most obvious and perhaps simplest. And I suspect I
>> am
>> the only one crazy enough to see any merit in exploring the
>> second.
>
> patientID yes, but probably also a DataSetID as we need to keep
> track (and
> separation) of the encounters/visits (instances of a dataset, "a
> filled
> form") in a more efficient way than we do in DataValue now.
> At least this is how its done in 1.4 Patient module and also for
> Survey type
> data.
>
>
>>
>> So I'm guessing Abyot will make a PatientDataElement with
>> something
>> like a patientID.
>
> Data elements do not have any direct reference to its source, so
> this should
> not be necessary. It is the datavalue that keeps this reference
> and which
> again is controlled by the dataset.

Sorry typo - I meant PatientDataValue ..

> We would in stead need a maintain Patients/Clients in a separate
> object, and
> pherhaps in a hierarchy (family, village). Lars also liked the
> idea of
> implementing the source object here, and I am open to that. After
> all that
> is why we created the source, to have diffeent types of sources to
> register
> data, not only orgunits.
> The peirod handling might also be different here as we always work
> on dates
> since these data are snapshots in time and not aggregtated over a
> certain
> period.
>
> Calle might have some useful input to how patient values are
> different from
> routine, apart from the security aspect we already discussed some
> weeks
> back.
>
>>
>> What else? Do we need a concept like an encounter (or visit) to
>> which
>> a date would be tied? Or can something be done with a
>> PeriodType?
>
> If we are going to reuse the DHIS concepts of data element,
> dataset, data
> entry form and data value then the dataset is the key here.
> In many ways routine datasets and "client" datasets are very
> similar, and "a
> filled form", or what might be called an instance of a dataset,
> contains
> values linked to data elements for a given period and a given
> source. Client
> encounters, rows from a register book, are also like that; a
> client name,
> multiple data elements (columns in the book) with values, and a
> date. After
> all its the final row of the register book, the total row
> aggregating all
> the encounters that gives the routine values for a monthly routine
> dataset.
> This example also illustrates how data elements overlap between
> client data
> and routine data, routine data are simply the total of "all
> clients" for the
> month. (This is not the case in survey audit type of datasets e.g.
> with
> maternal detah audits, but for standard CHIS it is mostly the
> case)
>
> If we keep track of the DatasetID in a ClientDataValue object we
> can the
> easily get an ecounter by querying for a client + a date + a
> dataset, or a
> list of all encounters (within a certain programme (dataset)) by
> querying
> for a client + a dataset. Of course it would be possible to get
> all data
> elements belonging to a dataset without directly referencing
> datasetid in
> datavalue, we do that today for dataset reports. Again, we need to
> check
> this with Calle or others, but I think client data are different
> in the way
> that a data element can exist in multiple datasets AND be
> registered for all
> of them for the same client and date, because the same data
> elements in
> different datasets might have different meanings and values. For
> routine
> this is not the case, that is why we di not keep a reference to
> dataset in
> datavalue, it is enough to use data element to describe the
> meaning of the
> data.
>
> So each encounter will be a data entry form, and its metadata will
> be
> controlled through the dataset object, similar to how its done for
> routine
> data. In the dataset object we need to specify what kind of data
> that is
> going to be registered,e.g. aggregated, disaggregated, survey(or
> routine,
> client, survey). Semi-permanent is then included in routine which
> is a bit
> confusing, that is why I prefer aggregated. Anyway, the principle
> is the
> same.

OK. This makes sense. A register object (for want of a better
term)
would be a specialisation of dataset.

> Datasets could be made even more dynamic, as we discussed on
> Skype, by
> adding other attributes like a set of header data elements and a
> set of
> footer data elements. These will be based on the same type of data
> elements,
> but stored or treated in a different way (in data entry and data
> value).Exactly how I am not sure, but we should look in detail at
> how 1.4
> treats header data elements.

Trying to piece together what a register might look like in xml:

<register name="Immunization register">
<dataset name="header" >
<dataelement name="???" >
<datavalue source="[clinicID]" period="???" value="34"
/>
</dataelement>
<dataelement name="???" >
<datavalue source="[clinicID]" period="???" value="34"
/>
</dataelement>
</dataset>

<patientdataset name="immunization data" />
<dataelement name="???">
<patientdatavalue source="[patientID1]" value="36"
date="01/01/2010" /> <!-- should date be done with a period type?
<patientdatavalue source="[patientID2]" value="43"
date="01/01/2010" />
<patientdatavalue source="[patientID3]" value="35"
date="01/01/2010" />
<patientdatavalue source="[patientID4]" value="22"
date="01/01/2010" />
</dataelement>
<dataelement name="???">
<patientdatavalue source="[patientID1]" value="36"
date="01/01/2010" />
<patientdatavalue source="[patientID2]" value="43"
date="01/01/2010" />
<patientdatavalue source="[patientID3]" value="35"
date="01/01/2010" />
<patientdatavalue source="[patientID4]" value="22"
date="01/01/2010" />
</dataelement>
</patientdataelement>

</register>

While typing the above it occurred to me that header AND footer are
probably not necessary for representing a register. What we really
need is a set of dataelements associated with the register and a set
associated with register rows. Whether the elements in the former
are
eventually rendered in the header or the footer is probably a
presentation issue which could be determined by, for example, the
name
or ID of the dataelement.

Also the above patientdataset is grouped on the dataelement axis.
Could also be grouped on source/patientID, making it closer in
analogy
to rows in a register. Though deriving the latter from the former
is
a simple enough transformation.

Abyot, returning to your original question, I don't know if having a
dataelement classification is necessary. If the dataelements are
always members of a dataset (at least one or only one ..) then
probably not. But I think you are right that it is only as you
hammer
out the detail that the truth might emerge ...

Cheers
Bob

> Ola
> --------
>
>
>
>
>
>
>
>
>
>>
>> Regards
>> Bob
>>
>> > And we also talked about the need to extend the DataSet object
>> > to
>> > include
>> > more properties that makes datasets more flexible and dynamic
>> > as we need
>> > them for CIS and also for survey data.
>> >
>> > So here I guess we all agree, there is no need to come up with
>> > a
>> > separate
>> > PatientDataElement.
>> >
>> >
>> > best regards,
>> > Ola Hodne Titlestad
>> > HISP
>> > University of Oslo
>> >
>> >
>> > On Wed, Jun 3, 2009 at 11:26 AM, Abyot Gizaw <abyota@gmail.com> >>>>>>>> >> > wrote:
>> >>
>> >> Hi All,
>> >>
>> >> Couldn't really convince myself as to the need to keep a
>> >> separate track
>> >> of
>> >> dataelements called patientdataelement. I just did an
>> >> implementation
>> >> for
>> >> patientdataelement ... but when giving it a thought about
>> >> linking it
>> >> with
>> >> some custom and predefiend values, then I see that one already
>> >> in place
>> >> by
>> >> Murod for the routine dataelements. And if we are going to
>> >> have a case
>> >> of
>> >> like recording multiple values for a single patient
>> >> dataelement, then
>> >> we
>> >> also will redo all the compex task of linking with options,
>> >> categories
>> >> and
>> >> their combinations, which is again in place for the routine
>> >> dataelements.
>> >>
>> >> If the need to separate the two - routine and patient is only
>> >> for the
>> >> purpose of managment, then I think it will be better if we
>> >> could
>> >> introduce
>> >> an attribute called 'classification' for dataelements. With
>> >> this
>> >> attribue we
>> >> can classify our dataelements like - Routine, Patient, Header,
>> >> Footer,...
>> >>
>> >> Any input will be appreciated.
>> >>
>> >> Thank you
>> >> Abyot.
>> >>
>> >> _______________________________________________
>> >> Mailing list: https://launchpad.net/~dhis2-devs
>> >> Post to : dhis2-devs@lists.launchpad.net
>> >> Unsubscribe : https://launchpad.net/~dhis2-devs
>> >> More help : https://help.launchpad.net/ListHelp
>> >>
>> >
>> >
>> > _______________________________________________
>> > Mailing list: https://launchpad.net/~dhis2-devs
>> > Post to : dhis2-devs@lists.launchpad.net
>> > Unsubscribe : https://launchpad.net/~dhis2-devs
>> > More help : https://help.launchpad.net/ListHelp
>> >
>> >
>
>

_______________________________________________
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp

_______________________________________________
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp

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.

chis_diagram.pdf (32.9 KB)

···

2009/6/4 Bob Jolliffe bobjolliffe@gmail.com

Hi

2009/6/4 Saptarshi Purkayastha sunbiz@gmail.com:

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@gmail.com

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@ifi.uio.no

2009/6/3 Abyot Gizaw abyota@gmail.com

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@ifi.uio.no

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@gmail.com

2009/6/3 Abyot Gizaw abyota@gmail.com

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

· ActivityPlan

o Owner – person (Health Extension Worker)

o Supervisor – person (Medical Officer)

o Date – date

o Activities – set

· 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 (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@gmail.com > > >>>>>>> wrote:

2009/6/3 Ola Hodne Titlestad olati@ifi.uio.no:

On Wed, Jun 3, 2009 at 12:04 PM, Bob Jolliffe > > >>>>>>>> > bobjolliffe@gmail.com wrote:

2009/6/3 Ola Hodne Titlestad olati@ifi.uio.no:

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
  1. 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:

  <dataelement name="????" >
        <datavalue source="[clinicID]" period="???" value="34"

/>

  </dataelement>
  <dataelement name="????" >
        <datavalue source="[clinicID]" period="???" value="34"

/>

  </dataelement>
   <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>

While typing the above it occurred to me that header AND footer are

probably not necessary for representing a register. What we really

need is a set of dataelements associated with the register and a set

associated with register rows. Whether the elements in the former

are

eventually rendered in the header or the footer is probably a

presentation issue which could be determined by, for example, the

name

or ID of the dataelement.

Also the above patientdataset is grouped on the dataelement axis.

Could also be grouped on source/patientID, making it closer in

analogy

to rows in a register. Though deriving the latter from the former

is

a simple enough transformation.

Abyot, returning to your original question, I don’t know if having a

dataelement classification is necessary. If the dataelements are

always members of a dataset (at least one or only one …) then

probably not. But I think you are right that it is only as you

hammer

out the detail that the truth might emerge …

Cheers

Bob

Ola


Regards

Bob

And we also talked about the need to extend the DataSet object

to

include

more properties that makes datasets more flexible and dynamic

as we need

them for CIS and also for survey data.

So here I guess we all agree, there is no need to come up with

a

separate

PatientDataElement.

best regards,

Ola Hodne Titlestad

HISP

University of Oslo

On Wed, Jun 3, 2009 at 11:26 AM, Abyot Gizaw abyota@gmail.com > > >>>>>>>> >> > wrote:

Hi All,

Couldn’t really convince myself as to the need to keep a

separate track

of

dataelements called patientdataelement. I just did an

implementation

for

patientdataelement … but when giving it a thought about

linking it

with

some custom and predefiend values, then I see that one already

in place

by

Murod for the routine dataelements. And if we are going to

have a case

of

like recording multiple values for a single patient

dataelement, then

we

also will redo all the compex task of linking with options,

categories

and

their combinations, which is again in place for the routine

dataelements.

If the need to separate the two - routine and patient is only

for the

purpose of managment, then I think it will be better if we

could

introduce

an attribute called ‘classification’ for dataelements. With

this

attribue we

can classify our dataelements like - Routine, Patient, Header,

Footer,…

Any input will be appreciated.

Thank you

Abyot.


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Hi

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.

Just had a go at importing dhis-api classes into argouml. Its a bit
messy but can work.

Regards
Bob

···

2009/6/4 Bob Jolliffe <bobjolliffe@gmail.com>:

2009/6/4 Saptarshi Purkayastha <sunbiz@gmail.com>:

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@gmail.com>

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@ifi.uio.no>

2009/6/3 Abyot Gizaw <abyota@gmail.com>

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@ifi.uio.no>

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@gmail.com>

2009/6/3 Abyot Gizaw <abyota@gmail.com>

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@gmail.com> >>>>>>>> wrote:

2009/6/3 Ola Hodne Titlestad <olati@ifi.uio.no>:
> On Wed, Jun 3, 2009 at 12:04 PM, Bob Jolliffe >>>>>>>>> > <bobjolliffe@gmail.com> wrote:
>>
>> 2009/6/3 Ola Hodne Titlestad <olati@ifi.uio.no>:
>> > Hi Abyot,
>> >
>> > If you read my summary e-mails just before the skype conference
>> > you will
>> > see
>> > that my suggestion was NOT to have a different type of data
>> > element, and
>> > I
>> > understood from the skype chat that we agreed on the same. What
>> > we
>> > talked
>> > about was to possibly make a separation in the user interface
>> > to avoid
>> > confusing the users, but in the background use the same
>> > DataElement
>> > object,
>> > but I am not sure that will always be needed as there are lot
>> > of overlap
>> > between routine and CHIS data elements.
>> >
>> > As you say, if we want to easily reuse datasets and data entry
>> > forms
>> > functionality we need to use the DataElement object also for
>> > client data
>> > elements. And of course we want to reuse what Murid has
>> > implemented
>> > regarding option lists for pre-defined values for data
>> > elements.
>> >
>> > The separation comes in DataValue as the PatientDataValue will
>> > need
>> > other
>> > properties than the (routine) DataValue.
>>
>> Agreed. But what would these properties be exactly? Two options
>> which have surfaced are:
>> 1. an additional patientID attribute; or
>> 2. no additional attribute - association of patient as a "source"
>>
>> The first is most obvious and perhaps simplest. And I suspect I
>> am
>> the only one crazy enough to see any merit in exploring the
>> second.
>
> patientID yes, but probably also a DataSetID as we need to keep
> track (and
> separation) of the encounters/visits (instances of a dataset, "a
> filled
> form") in a more efficient way than we do in DataValue now.
> At least this is how its done in 1.4 Patient module and also for
> Survey type
> data.
>
>
>>
>> So I'm guessing Abyot will make a PatientDataElement with
>> something
>> like a patientID.
>
> Data elements do not have any direct reference to its source, so
> this should
> not be necessary. It is the datavalue that keeps this reference
> and which
> again is controlled by the dataset.

Sorry typo - I meant PatientDataValue ..

> We would in stead need a maintain Patients/Clients in a separate
> object, and
> pherhaps in a hierarchy (family, village). Lars also liked the
> idea of
> implementing the source object here, and I am open to that. After
> all that
> is why we created the source, to have diffeent types of sources to
> register
> data, not only orgunits.
> The peirod handling might also be different here as we always work
> on dates
> since these data are snapshots in time and not aggregtated over a
> certain
> period.
>
> Calle might have some useful input to how patient values are
> different from
> routine, apart from the security aspect we already discussed some
> weeks
> back.
>
>>
>> What else? Do we need a concept like an encounter (or visit) to
>> which
>> a date would be tied? Or can something be done with a
>> PeriodType?
>
> If we are going to reuse the DHIS concepts of data element,
> dataset, data
> entry form and data value then the dataset is the key here.
> In many ways routine datasets and "client" datasets are very
> similar, and "a
> filled form", or what might be called an instance of a dataset,
> contains
> values linked to data elements for a given period and a given
> source. Client
> encounters, rows from a register book, are also like that; a
> client name,
> multiple data elements (columns in the book) with values, and a
> date. After
> all its the final row of the register book, the total row
> aggregating all
> the encounters that gives the routine values for a monthly routine
> dataset.
> This example also illustrates how data elements overlap between
> client data
> and routine data, routine data are simply the total of "all
> clients" for the
> month. (This is not the case in survey audit type of datasets e.g.
> with
> maternal detah audits, but for standard CHIS it is mostly the
> case)
>
> If we keep track of the DatasetID in a ClientDataValue object we
> can the
> easily get an ecounter by querying for a client + a date + a
> dataset, or a
> list of all encounters (within a certain programme (dataset)) by
> querying
> for a client + a dataset. Of course it would be possible to get
> all data
> elements belonging to a dataset without directly referencing
> datasetid in
> datavalue, we do that today for dataset reports. Again, we need to
> check
> this with Calle or others, but I think client data are different
> in the way
> that a data element can exist in multiple datasets AND be
> registered for all
> of them for the same client and date, because the same data
> elements in
> different datasets might have different meanings and values. For
> routine
> this is not the case, that is why we di not keep a reference to
> dataset in
> datavalue, it is enough to use data element to describe the
> meaning of the
> data.
>
> So each encounter will be a data entry form, and its metadata will
> be
> controlled through the dataset object, similar to how its done for
> routine
> data. In the dataset object we need to specify what kind of data
> that is
> going to be registered,e.g. aggregated, disaggregated, survey(or
> routine,
> client, survey). Semi-permanent is then included in routine which
> is a bit
> confusing, that is why I prefer aggregated. Anyway, the principle
> is the
> same.

OK. This makes sense. A register object (for want of a better
term)
would be a specialisation of dataset.

> Datasets could be made even more dynamic, as we discussed on
> Skype, by
> adding other attributes like a set of header data elements and a
> set of
> footer data elements. These will be based on the same type of data
> elements,
> but stored or treated in a different way (in data entry and data
> value).Exactly how I am not sure, but we should look in detail at
> how 1.4
> treats header data elements.

Trying to piece together what a register might look like in xml:

<register name="Immunization register">
<dataset name="header" >
<dataelement name="???" >
<datavalue source="[clinicID]" period="???" value="34"
/>
</dataelement>
<dataelement name="???" >
<datavalue source="[clinicID]" period="???" value="34"
/>
</dataelement>
</dataset>

<patientdataset name="immunization data" />
<dataelement name="???">
<patientdatavalue source="[patientID1]" value="36"
date="01/01/2010" /> <!-- should date be done with a period type?
<patientdatavalue source="[patientID2]" value="43"
date="01/01/2010" />
<patientdatavalue source="[patientID3]" value="35"
date="01/01/2010" />
<patientdatavalue source="[patientID4]" value="22"
date="01/01/2010" />
</dataelement>
<dataelement name="???">
<patientdatavalue source="[patientID1]" value="36"
date="01/01/2010" />
<patientdatavalue source="[patientID2]" value="43"
date="01/01/2010" />
<patientdatavalue source="[patientID3]" value="35"
date="01/01/2010" />
<patientdatavalue source="[patientID4]" value="22"
date="01/01/2010" />
</dataelement>
</patientdataelement>

</register>

While typing the above it occurred to me that header AND footer are
probably not necessary for representing a register. What we really
need is a set of dataelements associated with the register and a set
associated with register rows. Whether the elements in the former
are
eventually rendered in the header or the footer is probably a
presentation issue which could be determined by, for example, the
name
or ID of the dataelement.

Also the above patientdataset is grouped on the dataelement axis.
Could also be grouped on source/patientID, making it closer in
analogy
to rows in a register. Though deriving the latter from the former
is
a simple enough transformation.

Abyot, returning to your original question, I don't know if having a
dataelement classification is necessary. If the dataelements are
always members of a dataset (at least one or only one ..) then
probably not. But I think you are right that it is only as you
hammer
out the detail that the truth might emerge ...

Cheers
Bob

> Ola
> --------
>
>
>
>
>
>
>
>
>
>>
>> Regards
>> Bob
>>
>> > And we also talked about the need to extend the DataSet object
>> > to
>> > include
>> > more properties that makes datasets more flexible and dynamic
>> > as we need
>> > them for CIS and also for survey data.
>> >
>> > So here I guess we all agree, there is no need to come up with
>> > a
>> > separate
>> > PatientDataElement.
>> >
>> >
>> > best regards,
>> > Ola Hodne Titlestad
>> > HISP
>> > University of Oslo
>> >
>> >
>> > On Wed, Jun 3, 2009 at 11:26 AM, Abyot Gizaw <abyota@gmail.com> >>>>>>>>> >> > wrote:
>> >>
>> >> Hi All,
>> >>
>> >> Couldn't really convince myself as to the need to keep a
>> >> separate track
>> >> of
>> >> dataelements called patientdataelement. I just did an
>> >> implementation
>> >> for
>> >> patientdataelement ... but when giving it a thought about
>> >> linking it
>> >> with
>> >> some custom and predefiend values, then I see that one already
>> >> in place
>> >> by
>> >> Murod for the routine dataelements. And if we are going to
>> >> have a case
>> >> of
>> >> like recording multiple values for a single patient
>> >> dataelement, then
>> >> we
>> >> also will redo all the compex task of linking with options,
>> >> categories
>> >> and
>> >> their combinations, which is again in place for the routine
>> >> dataelements.
>> >>
>> >> If the need to separate the two - routine and patient is only
>> >> for the
>> >> purpose of managment, then I think it will be better if we
>> >> could
>> >> introduce
>> >> an attribute called 'classification' for dataelements. With
>> >> this
>> >> attribue we
>> >> can classify our dataelements like - Routine, Patient, Header,
>> >> Footer,...
>> >>
>> >> Any input will be appreciated.
>> >>
>> >> Thank you
>> >> Abyot.
>> >>
>> >> _______________________________________________
>> >> Mailing list: https://launchpad.net/~dhis2-devs
>> >> Post to : dhis2-devs@lists.launchpad.net
>> >> Unsubscribe : https://launchpad.net/~dhis2-devs
>> >> More help : https://help.launchpad.net/ListHelp
>> >>
>> >
>> >
>> > _______________________________________________
>> > Mailing list: https://launchpad.net/~dhis2-devs
>> > Post to : dhis2-devs@lists.launchpad.net
>> > Unsubscribe : https://launchpad.net/~dhis2-devs
>> > More help : https://help.launchpad.net/ListHelp
>> >
>> >
>
>

_______________________________________________
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp

_______________________________________________
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp

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@gmail.com

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@gmail.com

Hi

2009/6/4 Saptarshi Purkayastha sunbiz@gmail.com:

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@gmail.com

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@ifi.uio.no

2009/6/3 Abyot Gizaw abyota@gmail.com

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@ifi.uio.no

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@gmail.com

2009/6/3 Abyot Gizaw abyota@gmail.com

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

· ActivityPlan

o Owner – person (Health Extension Worker)

o Supervisor – person (Medical Officer)

o Date – date

o Activities – set

· 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 (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@gmail.com > > > > >>>>>>> wrote:

2009/6/3 Ola Hodne Titlestad olati@ifi.uio.no:

On Wed, Jun 3, 2009 at 12:04 PM, Bob Jolliffe > > > > >>>>>>>> > bobjolliffe@gmail.com wrote:

2009/6/3 Ola Hodne Titlestad olati@ifi.uio.no:

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
  1. 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:

  <dataelement name="????" >
        <datavalue source="[clinicID]" period="???" value="34"

/>

  </dataelement>
  <dataelement name="????" >
        <datavalue source="[clinicID]" period="???" value="34"

/>

  </dataelement>
   <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>

While typing the above it occurred to me that header AND footer are

probably not necessary for representing a register. What we really

need is a set of dataelements associated with the register and a set

associated with register rows. Whether the elements in the former

are

eventually rendered in the header or the footer is probably a

presentation issue which could be determined by, for example, the

name

or ID of the dataelement.

Also the above patientdataset is grouped on the dataelement axis.

Could also be grouped on source/patientID, making it closer in

analogy

to rows in a register. Though deriving the latter from the former

is

a simple enough transformation.

Abyot, returning to your original question, I don’t know if having a

dataelement classification is necessary. If the dataelements are

always members of a dataset (at least one or only one …) then

probably not. But I think you are right that it is only as you

hammer

out the detail that the truth might emerge …

Cheers

Bob

Ola


Regards

Bob

And we also talked about the need to extend the DataSet object

to

include

more properties that makes datasets more flexible and dynamic

as we need

them for CIS and also for survey data.

So here I guess we all agree, there is no need to come up with

a

separate

PatientDataElement.

best regards,

Ola Hodne Titlestad

HISP

University of Oslo

On Wed, Jun 3, 2009 at 11:26 AM, Abyot Gizaw abyota@gmail.com > > > > >>>>>>>> >> > wrote:

Hi All,

Couldn’t really convince myself as to the need to keep a

separate track

of

dataelements called patientdataelement. I just did an

implementation

for

patientdataelement … but when giving it a thought about

linking it

with

some custom and predefiend values, then I see that one already

in place

by

Murod for the routine dataelements. And if we are going to

have a case

of

like recording multiple values for a single patient

dataelement, then

we

also will redo all the compex task of linking with options,

categories

and

their combinations, which is again in place for the routine

dataelements.

If the need to separate the two - routine and patient is only

for the

purpose of managment, then I think it will be better if we

could

introduce

an attribute called ‘classification’ for dataelements. With

this

attribue we

can classify our dataelements like - Routine, Patient, Header,

Footer,…

Any input will be appreciated.

Thank you

Abyot.


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

I guess we all agree with this - I agree!

···

On Thu, Jun 4, 2009 at 12:45 PM, Ola Hodne Titlestad olati@ifi.uio.no 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)
  1. 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
  1. 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)
  1. 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,
  1. 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@gmail.com

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@gmail.com

Hi

2009/6/4 Saptarshi Purkayastha sunbiz@gmail.com:

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@gmail.com

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@ifi.uio.no

2009/6/3 Abyot Gizaw abyota@gmail.com

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@ifi.uio.no

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@gmail.com

2009/6/3 Abyot Gizaw abyota@gmail.com

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

· ActivityPlan

o Owner – person (Health Extension Worker)

o Supervisor – person (Medical Officer)

o Date – date

o Activities – set

· 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 (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@gmail.com > > > > > > >>>>>>> wrote:

2009/6/3 Ola Hodne Titlestad olati@ifi.uio.no:

On Wed, Jun 3, 2009 at 12:04 PM, Bob Jolliffe > > > > > > >>>>>>>> > bobjolliffe@gmail.com wrote:

2009/6/3 Ola Hodne Titlestad olati@ifi.uio.no:

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
  1. 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:

  <dataelement name="????" >
        <datavalue source="[clinicID]" period="???" value="34"

/>

  </dataelement>
  <dataelement name="????" >
        <datavalue source="[clinicID]" period="???" value="34"

/>

  </dataelement>
   <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>

While typing the above it occurred to me that header AND footer are

probably not necessary for representing a register. What we really

need is a set of dataelements associated with the register and a set

associated with register rows. Whether the elements in the former

are

eventually rendered in the header or the footer is probably a

presentation issue which could be determined by, for example, the

name

or ID of the dataelement.

Also the above patientdataset is grouped on the dataelement axis.

Could also be grouped on source/patientID, making it closer in

analogy

to rows in a register. Though deriving the latter from the former

is

a simple enough transformation.

Abyot, returning to your original question, I don’t know if having a

dataelement classification is necessary. If the dataelements are

always members of a dataset (at least one or only one …) then

probably not. But I think you are right that it is only as you

hammer

out the detail that the truth might emerge …

Cheers

Bob

Ola


Regards

Bob

And we also talked about the need to extend the DataSet object

to

include

more properties that makes datasets more flexible and dynamic

as we need

them for CIS and also for survey data.

So here I guess we all agree, there is no need to come up with

a

separate

PatientDataElement.

best regards,

Ola Hodne Titlestad

HISP

University of Oslo

On Wed, Jun 3, 2009 at 11:26 AM, Abyot Gizaw abyota@gmail.com > > > > > > >>>>>>>> >> > wrote:

Hi All,

Couldn’t really convince myself as to the need to keep a

separate track

of

dataelements called patientdataelement. I just did an

implementation

for

patientdataelement … but when giving it a thought about

linking it

with

some custom and predefiend values, then I see that one already

in place

by

Murod for the routine dataelements. And if we are going to

have a case

of

like recording multiple values for a single patient

dataelement, then

we

also will redo all the compex task of linking with options,

categories

and

their combinations, which is again in place for the routine

dataelements.

If the need to separate the two - routine and patient is only

for the

purpose of managment, then I think it will be better if we

could

introduce

an attribute called ‘classification’ for dataelements. With

this

attribue we

can classify our dataelements like - Routine, Patient, Header,

Footer,…

Any input will be appreciated.

Thank you

Abyot.


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp