2009/6/4 Bob Jolliffe <bobjolli...@gmail.com>: > Hi > > 2009/6/4 Saptarshi Purkayastha <sun...@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.
Just had a go at importing dhis-api classes into argouml. Its a bit messy but can work. Regards Bob >>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 <aby...@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 <ol...@ifi.uio.no> >>>> >>>> 2009/6/3 Abyot Gizaw <aby...@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 <ol...@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 <aby...@gmail.com> >>>>>>> >>>>>>> >>>>>>> 2009/6/3 Abyot Gizaw <aby...@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 <bobjolli...@gmail.com> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> 2009/6/3 Ola Hodne Titlestad <ol...@ifi.uio.no>: >>>>>>>>> > On Wed, Jun 3, 2009 at 12:04 PM, Bob Jolliffe >>>>>>>>> > <bobjolli...@gmail.com> wrote: >>>>>>>>> >> >>>>>>>>> >> 2009/6/3 Ola Hodne Titlestad <ol...@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 <aby...@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 >> >> > _______________________________________________ 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
