2009/6/3 Abyot Gizaw <[email protected]> > 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 <[email protected]>wrote: > >> 2009/6/3 Ola Hodne Titlestad <[email protected]>: >> > On Wed, Jun 3, 2009 at 12:04 PM, Bob Jolliffe <[email protected]> >> wrote: >> >> >> >> 2009/6/3 Ola Hodne Titlestad <[email protected]>: >> >> > 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 <[email protected]> >> 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<https://launchpad.net/%7Edhis2-devs> >> >> >> Post to : [email protected] >> >> >> Unsubscribe : >> >> >> https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs> >> >> >> More help : https://help.launchpad.net/ListHelp >> >> >> >> >> > >> >> > >> >> > _______________________________________________ >> >> > Mailing list: >> >> > https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs> >> >> > Post to : [email protected] >> >> > Unsubscribe : >> >> > https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs> >> >> > More help : https://help.launchpad.net/ListHelp >> >> > >> >> > >> > >> > >> > >
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
