[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnumed-devel] Re: Gnumed-devel Digest, Vol 6, Issue 37
From: |
sjtan |
Subject: |
[Gnumed-devel] Re: Gnumed-devel Digest, Vol 6, Issue 37 |
Date: |
26 May 2003 10:25:55 +1000 |
On Sun, 2003-05-25 at 21:03, address@hidden wrote:
> Send Gnumed-devel mailing list submissions to
> address@hidden
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.gnu.org/mailman/listinfo/gnumed-devel
> or, via email, send a message with subject or body 'help' to
> address@hidden
>
> You can reach the person managing the list at
> address@hidden
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Gnumed-devel digest..."
>
>
> Today's Topics:
>
> 1. Re: Re: Gnumed-devel Digest, Vol 6, Issue 35
> 2. re: openehr (sjtan)
> 3. Re: Gnumed-devel Digest, Vol 6, Issue 36 (sjtan)
> 4. PropertySupport (sjtan)
> 5. Re: PropertySupport (Ian Haywood)
>
>
> ----------------------------------------------------------------------
>
> Date: Sun, 25 May 2003 01:32:49 +0200 (MEST)
> From: address@hidden
> To: address@hidden
> Subject: Re: [Gnumed-devel] Re: Gnumed-devel Digest, Vol 6, Issue 35
> Message-ID: <address@hidden>
> References: <address@hidden>
> Content-Type: text/plain; charset="iso-8859-1"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 8bit
> Precedence: list
> Message: 1
>
> > > > actually, I'm having a hard time trying to work out how to access the
>
> > > > gmclinical tables.
> > > One of the problems may be that one needs to understand the
> > > domain at least partially to see how this is supposed to
> > > work. Have you read the writeup on the EMR structure ?
> > >
> > Where's the write-up?
> client/doc/TODO/developer-guide.txt
>
> > I suppose my problem is with the distinction between Diagnosis , and
> > Clin Health Issue which seems to be something to hold arbitrary
> > text of 128 character, and be associated with a clinical episode which
> ...
> IMHO, to a doctor the whole thing makes sense, semantically. If you need
> more explanation after
> reading the writeup please ask again.
>
> > First of all, the doctor
> > would need a pretty good retrospectoscope to figure out which items
> > occuring at an encounter actually were part of a long running episode
> > regarding a particular issue
> No, this type of thing feels perfectly natural to a health professional (or
> should).
>
> Karsten
>
>
> --
> +++ GMX - Mail, Messaging & more http://www.gmx.net +++
> Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!
>
>
>
> ------------------------------
>
> Date: 25 May 2003 10:45:26 +1000
> From: sjtan <address@hidden>
> To: gnumed <address@hidden>
> Subject: [Gnumed-devel] re: openehr
> Message-ID: <address@hidden>
> In-Reply-To: <address@hidden>
> References: <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1
> MIME-Version: 1.0
> Content-Transfer-Encoding: quoted-printable
> Precedence: list
> Message: 2
>
>
> it's changed, some stuff available now.
> Looking at the reference data_structures_rm_1_3.pdf document,
> it's very Eiffel oriented;
> looking at the table structures, even the datatypes functions are
> defined
>
> TABLE_S
> ------------------
> def row_count()
> def column_count()
> def row_names()
> def_column_names()
> def ith_row(i)
> def has_row_with_name(key)
> def has_column_with_name(key)
> def named_row(key)
> def has_row_with_key(keySet)
> def element_at_cell_ij(i, j)
> element_at_named_cell( row_key, col_key)
>
> and these are the encoding rules:4.2.4.2 =20
>
> TABLE_S Structural Encoding Rules
> The TABLE_S encoding rules are as follows:
> =B7 Each column is represented by a COMPOUND, whose name value is the
> name of the column.
> =B7 Each row item in a given column is represented by an ELEMENT under
> the relevant column
> COMPOUND.
> =B7 The name of each ELEMENT object is the name of its column.
>
>
> something like
>
> name =3D 'name'
> index =3D 'index'
> value =3D 'value'
>
> table.cols =3D []
> for x in range (n_cols):
> COMPOUND =3D { name: col_names[x], items =3D [] }
> table.cols.append(COMPOUND)
> for y in range( n_rows):
> ELEMENT =3D { name : col_names[x], index : y, value =3D None
> }=20
> COMPOUND.items.append(ELEMENT)
>
>
>
> Does using OpenEHR structures invalidate GPL ?
>
> =09
> =09
>
>
>
>
>
>
>
>
>
> ------------------------------
>
> Date: 25 May 2003 10:59:40 +1000
> From: sjtan <address@hidden>
> To: gnumed <address@hidden>
> Subject: [Gnumed-devel] Re: Gnumed-devel Digest, Vol 6, Issue 36
> Message-ID: <address@hidden>
> In-Reply-To: <address@hidden>
> References: <address@hidden>
> Content-Type: text/plain
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Precedence: list
> Message: 3
>
> On Sat, 2003-05-24 at 20:51, address@hidden wrote:
> > Send Gnumed-devel mailing list submissions to
> > address@hidden
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > http://mail.gnu.org/mailman/listinfo/gnumed-devel
> > or, via email, send a message with subject or body 'help' to
> > address@hidden
> >
> > You can reach the person managing the list at
> > address@hidden
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Gnumed-devel digest..."
> >
> >
> > Today's Topics:
> >
> > 1. Problems installing gnumed (Roberto Mello)
> > 2. Re: Problems installing gnumed (Horst Herb)
> > 3. Re: Problems installing gnumed
> > 4. Re: Gnumed-devel Digest, Vol 6, Issue 35 (sjtan)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Date: Fri, 23 May 2003 13:51:21 -0600
> > From: Roberto Mello <address@hidden>
> > To: address@hidden
> > Subject: [Gnumed-devel] Problems installing gnumed
> > Message-ID: <address@hidden>
> > Content-Type: text/plain; charset=iso-8859-1
> > MIME-Version: 1.0
> > Precedence: list
> > Message: 1
> >
> > Hello,
> >
> > My name is Roberto Mello and I'm evaluating GNUmed for my mom's clinic.
> > It's been my dream to use a free (speech) medical system for my mom's
> > practice, and I think GNUmed is such system.
> >
> > I'm from Brazil so I'd be translating the system to portuguese as well as
> > helping with development and bug fixing where necessary. I'm an
> > experienced developer, although not so much with wxPython yet.
> >
> > I haven't been able to install GNUMed fully<F5>. I loaded the three sql
> > files described on the documents, but when I run it I get a PANIC after
> > logging in:
> >
> > [PANIC]
> > (/home/rbm/documents/projects/gnumed/gnumed/client/python-common/gmPG.py::run_query:497):
> > query >>>SELECT description from v_i18n_enum_encounter_type;<<< failed
> >
> > I've grep'ed around for that table and I found it, but I don't know how
> > it's supposed to be loaded (the sequence, that is).
> >
> > I'm using GNUMed from CVS of a couple days ago.
> >
> > Is there an update page somewhere where I cansee the state of the several
> > modules of gnumed? Right now I'm more interested in the patient tracking
> > capabilities of gnumed than in its decision-support features.
> >
> > Any help and guidance would be appreciated. I'd really like to free
> > ourselves from the proprietary system we are forced to use at the moment.
> >
> > -Roberto
> >
> > --
> > +------------| Roberto Mello - http://www.brasileiro.net |------------+
> > Computer Science, Utah State University - http://www.usu.edu
> > USU Free Software & GNU/Linux Club - http://fslc.usu.edu
> > OpenACS - Enterprise free web toolkit - http://openacs.org
> > Pimentus annus alter, refrescum est.
> >
> >
> give us a hand:
> 1. assume you are the sole developer of the domain (one level of
> indirection) layer between the gui and frontend.
> Implement the layer, the connection adapters to the frontend
> components, and the layer adapters to the "current" database.
> (only 3 layers spanning the whole gui system, not much really)
>
> 2. autocratically allow or deny changes to your domain system.
>
> 3. do it in 2 weeks.
>
> that's all we ask of you.
>
>
>
>
> ------------------------------
>
> Date: Sun, 25 May 2003 13:08:08 +1000
> From: sjtan <address@hidden>
> To: gnumed <address@hidden>
> Subject: [Gnumed-devel] PropertySupport
> Message-ID: <address@hidden>
> Content-Type: text/plain
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7BIT
> Precedence: list
> Message: 4
>
>
>
> I've made a PropertySupport class like java.beans.PropertySupport.
>
> There is a PropertySupported class in the file, which can be used
> to notify assignments to a class instances self.
>
>
> If the gmEditArea was reverted to it's old simple,
> self.txt_blah = wxTextCtrl
> self.btn_OK = wxButton
>
> then those component creations can be detected, but only if
> assigned to the self that is a PropertySupported class.
>
>
> you can easily add widget construction event detection to the gui
> construction.
>
> It is also possible to detect the TBOX_list assignment , but
> the TBOX would have to be from a UserDict subclass that inherits
> PropertySupported.
>
>
> - Look, prior to the recent changes in gmEditArea , all the fields
> in the panel were signalling through handler classes which put the
> changes into a dictionary. The easiest thing to do then was to
> make a dictionary that could update a database e.g. by calling
> myDict.save() or something like that, and then instantiating that
> dictionary as the dictionaries for the handlers.
>
> Now that is broken by the re-write of gmEditArea ; so I'm asking if
> anyone is unhappy about the property support idea, before I waste my
> time again.
>
>
> - this property support mechanism was intended to be used for connecting
> domain classes together, but I noticed it had the possibility of working
> for the problem of extracting the data entry components from a cleanly
> written prototype gui, so that adapters (wxValidator) can be added to
> the components , which can then communicate with the database or a
> domain model .
>
>
>
>
>
> ------------------------------
>
> Date: Sun, 25 May 2003 16:15:52 +1000
> From: Ian Haywood <address@hidden>
> To: address@hidden
> Subject: Re: [Gnumed-devel] PropertySupport
> Message-ID: <address@hidden>
> In-Reply-To: <address@hidden>
> References: <address@hidden>
> Content-Type: multipart/signed; protocol="application/pgp-signature";
> boundary="=.JbmnZ1_vl4e)w:"
> MIME-Version: 1.0
> Precedence: list
> Message: 5
>
> --=.JbmnZ1_vl4e)w:
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: 7bit
>
> On Sun, 25 May 2003 13:08:08 +1000
> sjtan <address@hidden> wrote:
>
> >
> >
> > I've made a PropertySupport class like java.beans.PropertySupport.
> >
> > There is a PropertySupported class in the file, which can be used
> > to notify assignments to a class instances self.
> >
> >
> > If the gmEditArea was reverted to it's old simple,
> > self.txt_blah = wxTextCtrl
> > self.btn_OK = wxButton
> >
> > then those component creations can be detected, but only if
> > assigned to the self that is a PropertySupported class.
>
> To be honest, I'm still having a lot of trouble understanding this.
> (I've never used Delphi or any of those things, the last time a
> wrote a non-UNIX program it was still called Turbo Pascal ;-)
>
> Apparantly, you are trying to parse the existing code to construct template
> files
> for event handlers on the various widgets. Is this right?
>
> Could you also, for those ignorant, explain what java.beans.PropetrySupported
> does?
>
> Another problem is most (actually, virtually all) of gnumed UI code is
> contained
> as plugins. Plugins are meant to be self-contained items of code, ideally one
> file,
> to do a specific job. Users can load and unload modules at anytime. A
> separate file
> to hold handlers complicates things, as it has to be loaded/unloaded in
> unison with
> its 'original' plugin file (but certainly doable).
>
> In addition, the current plugin system is poorly designed, as has been
> commented on before, and
> will be reworked in the (hopefully) near future. This would be a good time to
> make sure Syan's
> work is intregrated with the overall plan, so it doesn't get broken again.
>
> Proposal:
>
> All our "hand-rolled" screen widgets, such as gmEditArea, inherit from
> gmWidget, so that they all
> update their values into the common dictionary (which is a member of the
> plugin object)
> Other widgets will be multiple inheritors of gmWidget and the wx original, to
> provide
> this functionality to all widgets we use (even if they are otherwise ordinary
> wx widgets)
>
> [can this end the need to scan files and add handlers in a separate file?
> Each widget could handle all of its
> own events. Or am I missing something?]
>
> Plugins then only need load () and save () methods to move the dictionary
> values to and from the
> backend database as Syan said.
>
> load () would be called on "patient_selected" (perhaps as a "lazy" function
> -- only when the plugin
> is shown onscreen)
>
> save () is more complex, perhaps the inherited behaviour should be a few
> seconds after the last widget is updated
> (or prior
> to another load () if it comes first), For the scripts widget at least, a
> specific button/function key
> is needed also (in order to save and clear the fields for the next
> prescription)
>
> Ian
>
>
>
> --=.JbmnZ1_vl4e)w:
> Content-Type: application/pgp-signature
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
>
> iD8DBQE+0F+eKPy8UudQZS4RAo2qAJ96JivK2Qs2FFMMAtCZxwkkTl5piwCgg4IP
> 0NtgWqiXWetl1O3qDuEElnU=
> =GvgL
> -----END PGP SIGNATURE-----
>
> --=.JbmnZ1_vl4e)w:--
>
>
>
> ------------------------------
>
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnumed-devel
>
>
> End of Gnumed-devel Digest, Vol 6, Issue 37
> *******************************************
It makes an object "push" state changes. when an attribute changes, e.g.
o.x = 1, then an event with name "x" , oldValue = None, newValue = 1 is
pushed onto any listeners (via their propertyChange(event) method)
registered with the object.
It was useful in java, so I put in , but it probably isn't necessary ;
you could just get a gmEditArea object and go through it's __dict__
method to find all the correctly named components starting with txt__ ,
and attach wxValidators to them , say a validator with a table name and
a field name which updates a database table when wxValidator.validate is
called , or just attach a eventHandler object instead which handle text
events.
Actually , in not sure in wxWindows, but in java, you could get the
topmost container, and recursively call getComponents() and test the
type of each component. if a component is a container, recurse and
call getComponents(), otherwise test if the component is a particular
type, get it's name, and attach a e.g.textListener (text event handler)
to it.
>Apparantly, you are trying to parse the existing code to construct
>template files
>for event handlers on the various widgets. Is this right?
The script idea was just to automate the writing of event handler
drudgery ; it's just about "separation of concerns"
( I'm beginning to think this is a way computer programming
educationalists push their consulting fees).
Look I've got another idea I'm trying out ;
I was playing with the java ant build system, reading about
Hibernate and Xdoclet, and was thinking why don't we
try this attribute programming thing,
and have a application generator program that reads a xml script the
defines a tree structured data structure, and a tree structured
view structure, and have required actions as attributes in each
view.
I'll post the idea as appgen at the client , server directory level.
Whether we could do it , or we all independently do it ( just for fun),
is another matter.
- [Gnumed-devel] Re: Gnumed-devel Digest, Vol 6, Issue 37,
sjtan <=