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