> > but in the end getting confused which one is the dataelement which one is > the dimension. Well the MD model can handle such a breakup I guess but the > point is not that. >
Well me too, and that is why I started all of this. My data entry screen (e.g. a paper form, collect OPD 1st Attendance Clinical Case of Malaria Under 1 with different patient status (OPD, IP, Deaths), different classes of diagnosis (Confirmed, Clinical) and different age groups. However, in the end what the district health officers want to know is as follows: How many cases of OPD, IP and Deaths of Malaria have their been, with possible slices of those dimensions (by age, comparing clinical and confirmed etc). By defining appropriate categories, I can see now how I can possible get this through a a DHIS report table, the datamart, or some other custom SQL query. But, the problem arises when there is some higher order dimensionality, that has not been defined in the categories. Such as, All cases of vector-borne diseases This category was not part of my original categories and might include (as I stated in my example) Malaria, Leishmaniasis, Dengue, etc aggregated together. If I wanted to get this, I suppose I could create a data element group for this. But what happens when I need more than one data element group, such as Communicable diseases, which might include vector borne, water borne, etc. > The point is, what users should do is I guess to first define what they need > from that functionality - what kind of data are they going to collect? what > does their dataentry screen look like? No, I totally disagree. For me the data entry screen is only a necessary artifact to answer the questions that need to. How many cases of under 1 clinical malaria have we had? What is the case fataility ratio for confirmed malaria cases? There are so many possibilities. > But how different > is the analysis going to be from our input formats? Very. I think I have given enough examples to support this. > Anyways for me a dimension is just an attribute to a dataelement. So before > talking about a dimension first we need to have a dataelement and > (logically) we can't mix the two! I completely agree with you, and this is why I am not comfortable with the current implementation. Dimensions are simply additional metadata added to a given observation, or measure. If you take a look at the OpenHealth data models, a measure has dimensions. DHIS appears to be built around three compulsory dimensions, which all measures should have: 1) What: Data element, which is essentially a description of what the observation can be classified as 2) When: A point in time (period) 3) Where: An organizational unit, or place. All other dimensions are simply bling that need to be added for the purpose of analysis. However the current model has to some degree mixed up data entry with analysis, and thus the conundrum that I find myself in. Regards, Jason _______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
