[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fwd: Re: [Gnumed-devel] About EMR items Value Objects
From: |
Karsten Hilbert |
Subject: |
Re: Fwd: Re: [Gnumed-devel] About EMR items Value Objects |
Date: |
Sat, 27 Mar 2004 22:52:48 +0100 |
User-agent: |
Mutt/1.3.22.1i |
Hi Carlos !
> Gnudmed-devel list mail seems to have some delay, i forward to you the mail...
A known issue occurring from time to time.
> Right. We can also add another useful field to base clase, instead of
> item_type. item_table: 'vaccination', 'lab_request', 'allergy'.
> I'm not really sure about it, but at first maybe we could use 'pk serial
> primary key' sql table field, at least to keep some track of the item...
Again, let's remind ourselves that we are trying to
encapsulate *business* objects. Tables, however, do not
correspond to business objects 1:1 because they are fairly
normalized. Thus a business object can span several tables
hence we need to keep track of several primary keys within
one such object.
> (along src_table, we can query db 'backwards' eg. health issues, etc...
> becouse we have their ids as foreign keys in item tables...)
Sure. For all business objects inheriting from clin_root_item
this could also be centralized.
> Oops, sorry it's correct ;) . We could provide in vos those simple
> get_XX_text_dump() just, as a quick text dump of its contents (that maybe
> could be used later in gmClinicalRecord.get_text_dump())...
Right on !
> But, the export
> tool would provide some methods that retrieve adecuate values object's fields
Exactly.
> to provide a more estructured text (as Karsten proposed):
[snip]
It's really quite simple: Ultimately we want to be able to
produce a patient printout, hand it to a random fellow doctor
and have her comprehend the information without any assumed
knowledge about GnuMed.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346