we could consider it - the only problem is that we have chosen the approach of using one column for all types of values. Most values are short numbers and using text as column type over varchar with fixed length implies a performance penalty. I am not sure how significant that overhead is with latest versions of postgresql/mysql. We could check it out. I guess you could do like Knut suggests for now and change the column type manually.
Hi - just to echo on Marko’s comment: PSI is also considering the use of a large, free text field, for doctor/ nurse to write free text observations that we don’t need to quantify, but we want to capture, so DHIS can work as a light electronic health record. We will try Knut’s suggestion on the mean time.
···
On Fri, Apr 26, 2013 at 8:48 AM, Lars Helge Øverland larshelge@gmail.com wrote:
Hi Marko,
we could consider it - the only problem is that we have chosen the approach of using one column for all types of values. Most values are short numbers and using text as column type over varchar with fixed length implies a performance penalty. I am not sure how significant that overhead is with latest versions of postgresql/mysql. We could check it out. I guess you could do like Knut suggests for now and change the column type manually.
We have a comment field available for the programinstance object. This is for general comments about a person in a program, a bit like a whiteboard that you can always see on top of the data entry form in Person Dashboard. This field is also limited to 255 characters, but we can extend it. We have a patientcomment object that is referenced in programinstance.
Would this meet your needs or you need to have a comment per program stage instance (encounter/visit)?
I guess we could link to a patientcomment from programstageinstance as well, and this way make comments available per stage instance?
Ola
···
On Fri, Apr 26, 2013 at 8:48 AM, Lars Helge Øverland larshelge@gmail.com wrote:
Hi Marko,
we could consider it - the only problem is that we have chosen the approach of using one column for all types of values. Most values are short numbers and using text as column type over varchar with fixed length implies a performance penalty. I am not sure how significant that overhead is with latest versions of postgresql/mysql. We could check it out. I guess you could do like Knut suggests for now and change the column type manually.
We are looking for a field at the encounter time - we wanted to create a massive entry space using a custom form, so the doctor/nurse can write whatever she/he wants, and limit structured information to 5-8 fields using option sets.
···
On Mon, Apr 29, 2013 at 8:34 PM, Ola Hodne Titlestad olati@ifi.uio.no wrote:
Hi Marko and Rodolfo,
We have a comment field available for the programinstance object. This is for general comments about a person in a program, a bit like a whiteboard that you can always see on top of the data entry form in Person Dashboard. This field is also limited to 255 characters, but we can extend it. We have a patientcomment object that is referenced in programinstance.
Would this meet your needs or you need to have a comment per program stage instance (encounter/visit)?
I guess we could link to a patientcomment from programstageinstance as well, and this way make comments available per stage instance?
Ola
Ola Hodne Titlestad (Mr)
HISP
Department of Informatics
University of Oslo
Mobile: +47 48069736
Home address: Eftasåsen 68, 0687 Oslo, Norway. Googlemaps link
Hi - just to echo on Marko’s comment: PSI is also considering the use of a large, free text field, for doctor/ nurse to write free text observations that we don’t need to quantify, but we want to capture, so DHIS can work as a light electronic health record. We will try Knut’s suggestion on the mean time.
Note: Please note my new email address, which I will be using for PSI related work: rmelia@knowming.com
On Fri, Apr 26, 2013 at 8:48 AM, Lars Helge Øverland larshelge@gmail.com wrote:
Hi Marko,
we could consider it - the only problem is that we have chosen the approach of using one column for all types of values. Most values are short numbers and using text as column type over varchar with fixed length implies a performance penalty. I am not sure how significant that overhead is with latest versions of postgresql/mysql. We could check it out. I guess you could do like Knut suggests for now and change the column type manually.
Such a fielt could be used to create an event with a SOAP structure.
JM
···
On Mon, Apr 29, 2013 at 8:34 PM, Ola Hodne Titlestad olati@ifi.uio.no wrote:
Hi Marko and Rodolfo,
We have a comment field available for the programinstance object. This is for general comments about a person in a program, a bit like a whiteboard that you can always see on top of the data entry form in Person Dashboard. This field is also limited to 255 characters, but we can extend it. We have a patientcomment object that is referenced in programinstance.
Would this meet your needs or you need to have a comment per program stage instance (encounter/visit)?
I guess we could link to a patientcomment from programstageinstance as well, and this way make comments available per stage instance?
Ola
Ola Hodne Titlestad (Mr)
HISP
Department of Informatics
University of Oslo
Mobile: +47 48069736
Home address: Eftasåsen 68, 0687 Oslo, Norway. Googlemaps link
Hi - just to echo on Marko’s comment: PSI is also considering the use of a large, free text field, for doctor/ nurse to write free text observations that we don’t need to quantify, but we want to capture, so DHIS can work as a light electronic health record. We will try Knut’s suggestion on the mean time.
Note: Please note my new email address, which I will be using for PSI related work: rmelia@knowming.com
On Fri, Apr 26, 2013 at 8:48 AM, Lars Helge Øverland larshelge@gmail.com wrote:
Hi Marko,
we could consider it - the only problem is that we have chosen the approach of using one column for all types of values. Most values are short numbers and using text as column type over varchar with fixed length implies a performance penalty. I am not sure how significant that overhead is with latest versions of postgresql/mysql. We could check it out. I guess you could do like Knut suggests for now and change the column type manually.