[Gnumed-devel] Re: Gnumed-devel Digest, Vol 6, Issue 35

[sjtan]

> 
> Date: Fri, 23 May 2003 14:54:05 +0200
> From: Karsten Hilbert <address@hidden>
> To: gnumed <address@hidden>
> Subject: Re: [Gnumed-devel] Re: Gnumed-devel Digest, Vol 6, Issue 34
> Message-ID: <address@hidden>
> In-Reply-To: <address@hidden>
> References: <address@hidden>
>       <address@hidden>
> Content-Type: text/plain; charset=us-ascii
> MIME-Version: 1.0
> Precedence: list
> Message: 3
> 
> > 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? Our EMR structure or the GEHR ?
I've read a little of HL7 and looked at some of the GEHR, and it 
seems to be boiling down to Identity mapping, or mapping fine grained 
concepts from one coding system to another, and back, so that a rule
based system which has semantics written into it are operating on the
same assumptions. (i.e. asthma might trigger a rule in two similiar rule
systems to warn against prescription of aspirin in presence of URTI ;
runny nose, coryza , give a high probability of presence of URTI
observation, and would notify the probability of presence , along with
the aspirin warning given the probability of presence of URTI; 
several occurences of coding for wheeze on examination observation
through the patient history might indicate a consideration for 
asthma investigation, resp function testing , and this could be
configured with a RecurrenceRule of wheezing ExaminationObservation
.. So what system are we going to use, not that we have learned to crawl
yet with a simple minded denormalized simple mapping.

Another problem is just how to map the current apparent tables : 
progress_notes(pat_id, time_loc_actorobserver_id, notes) , 
immunization( pat_id, time_loc_actorobserver_id, type_id, vendor_id,
site_id, route_id, batch_id), prescription(  pat_id,
time_loc_actorobserver_id, type_id, vendor_id, protocol_id, dosing_id,
duration, reason_id) , referral_letter( pat _id,
time_loc_actorobserver_id, to_provider_id, delivery_mode_id ),
referral_letter_links(  pat_id, time_loc_actorobserver_id, link_type,
link_id) , pathology( pat_id, time_loc_actorobserver_id, state, type_id,
reason_id, form_id, report_id), reports ( pat_id,
time_loc_actorobserver_id, type, regarding_time_loc_actorobserver_id,
content_id) , content_link ( content_id, type_id, link_id) ....
map these to a EHR , which might be something like NodeCollection , 
TimePlaceCategory, ArbitraryImportantCategory, NodeCollection many to
one association with ArbitraryImportantCategory,  NodeCollection one to
many association with Node,  everything else Phenomenon whatever is a
Node but with extra fields without a dictionary for field names and
types .... maybe it could also be Node( node_type_id, xml_content  ...)
Node_type ( url_for_xml_xsd xml document definition ,
default_xml_xsd_content, date_updated ) 

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
is a postmortem text after a clinical_encounter , and both could be
split associated with many clin_root_items , so that a clin_root_item is
associated by time_space_provider to a clin_encounter but refer to a
different one and only one clin_episode regarding a particular issue,
whilst another clinical_root_item refers to the same encounter but is
regarded as a different clinical_episode because it refers to another
issue ( and only one issue), and a different encounter at another time
might refer to the same clinical_episode regarding the same issue, even
though it could be a different time and place . 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 , let alone trying to AUTOMATE this?




> Another tangent here is that it may help to read the code in
> client/business/ for one approach to how to link to the
> clinical data backend.
> 
> > The views and update triggers in gmIdentityViews are 
> > fairly straight forward,
> They aren't particularly refined, IMHO, and useful for some
> means and not for others. What is in gmclinical* is a bit
> further along (conceptually), I think.
> 
> > and after trying to do the handler skeletons, I
> > realize SQL triggers are probably the clearest way of doing things.
> AFAIK, it is considered good practice to access database
> columns via functions unless speed issues prevent that.
> 
> > But after  I stared at the gmclinical tables for a few hours, trying to
> > write my first SQL trigger, I whimpered back to my java IDE toy.
> What exactly were you trying to do ? Unfortunately, not even
> the best IDE can do away with the need for understanding the
> underlying principles and concepts. It can merely help in
> making drudgery less, well, boresome.
> 
> > What about starting with a dead simple mapping,
> Download OSCAR if you want that. Or most of the other MFOSS
> apps for that matter. If you don't want any mapping except for
> what you make up on the spot in a whim then download the OIO.
> 
> > then later normalizing
> > it by making the simple tables views with triggers?
> What is causing the problems with the schema in gmclinical* ?
> I admit it is non-trivial. I'm happy to explain more than I
> already did in the writeup. Maybe something's skewed somewhere,
> too.
> 
> Karsten
> -- 
> GPG key ID E4071346 @ wwwkeys.pgp.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
> 
> 
> ------------------------------
> 
> Date: Fri, 23 May 2003 15:14:52 +0200
> From: Karsten Hilbert <address@hidden>
> To: address@hidden
> Subject: Re: [Gnumed-devel] Re: Gnumed-devel Digest, Vol 6, Issue 34
> Message-ID: <address@hidden>
> In-Reply-To: <address@hidden>
> References: <address@hidden>
>       <address@hidden>
>       <address@hidden>
> Content-Type: text/plain; charset=us-ascii
> MIME-Version: 1.0
> Precedence: list
> Message: 4
> 
> > The storage of the FK is neccessary to facilitate house keeping scripts for 
> > later updates, since apparently identical referenced data can belong to 
> > different foreign keys.
> Unfortunately, yes:
> 
> create table state (
>     id serial primary key,
>     id_country integer references iso_codes_country(id),
>     code varchar(20),
>     "name" varchar(255),
>     unique (id_country, code, "name")
> );
> 
> create table address (
>     id serial primary key,
>     fk_code varchar(20) references state(code),
>     fk_name varchar(255) references state(name),
>     ...
> );
> 
> Problems:
> 
> fk_code and fk_name don't work since there are no unique
> constraints on the referenced columns in table state. Also,
> there can't be because they ARE NOT unique - hence the
> multiple column unique constraint in the state table.
> 
> Karsten
> -- 
> GPG key ID E4071346 @ wwwkeys.pgp.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
> 
> 
> ------------------------------
> 
> Date: Fri, 23 May 2003 15:42:17 +0200
> From: Karsten Hilbert <address@hidden>
> To: GNUmed list <address@hidden>
> Subject: Re: [Gnumed-devel] Re: Gnumed-devel Digest, Vol 6, Issue 34
> Message-ID: <address@hidden>
> In-Reply-To: <address@hidden>
> References: <address@hidden>
>       <address@hidden>
>       <address@hidden>
>       <address@hidden>
> Content-Type: text/plain; charset=us-ascii
> MIME-Version: 1.0
> Precedence: list
> Message: 5
> 
> >> work. Have you read the writeup on the EMR structure ?
> > Where can I find the writeup?
> client/doc/TODO/developer-guide.txt
> 
> Belongs into client/doc/developer-manual/ but no one has been
> up to moving it there.
> 
> Karsten
> -- 
> GPG key ID E4071346 @ wwwkeys.pgp.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
> 
> 
> ------------------------------
> 
> Date: Fri, 23 May 2003 15:21:17 +0200
> From: Karsten Hilbert <address@hidden>
> To: address@hidden
> Subject: Re: [Gnumed-devel] Re: Gnumed-devel Digest, Vol 6, Issue 34
> Message-ID: <address@hidden>
> In-Reply-To: <address@hidden>
> References: <address@hidden>
>       <address@hidden>
>       <address@hidden>
> Content-Type: text/plain; charset=us-ascii
> MIME-Version: 1.0
> Precedence: list
> Message: 6
> 
> > In some cases I'd even go for the following approach for performance (and 
> > sort 
> > of simplicity) reasons:
> > where normalized data is small (example: typical enumerations) we should 
> > store 
> > BOTH data and foreign key to data in the table. A trigger will intercept 
> > inserts and updates and make sure that referential integrity is maintained 
> > by 
> > using the referenced table as "lookup" only.
> This is only necessary in cases where the "actually"
> referenced column is NOT unique (as in the example in the
> previous mail). For other cases where the referenced column IS
> (supposed to be) unique the need for insert/update triggered
> referential integrity checks goes away simply by referencing
> the real column instead of the (artifical) primary key of the
> referenced table:
> 
> create table _enum_hx_type (
>     id serial primary key,
>     "name" unique varchar(50)
> );
> 
> create table hx_entry (
>     id serial primary key,
>     fk_type varchar(50) references _enum_hx_type(name),
>     data varchar
> );
> 
> Here, _enum_hx_type."name" is supposed to be unique by design
> anyways, so we can just reference that and let PostgreSQL do
> the hard work.
> 
> Karsten
> -- 
> GPG key ID E4071346 @ wwwkeys.pgp.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
> 
> 
> ------------------------------
> 
> Date: Fri, 23 May 2003 15:23:41 +0200
> From: Karsten Hilbert <address@hidden>
> To: address@hidden
> Subject: Re: [Gnumed-devel] Re: Gnumed-devel Digest, Vol 6, Issue 34
> Message-ID: <address@hidden>
> In-Reply-To: <address@hidden>
> References: <address@hidden>
>       <address@hidden>
>       <address@hidden>
> Content-Type: text/plain; charset=us-ascii
> MIME-Version: 1.0
> Precedence: list
> Message: 7
> 
> >> What about starting with a dead simple mapping , then later normalizing
> [...]
> 
> > In some cases I'd even go for the following approach for performance (and 
> > sort 
> > of simplicity) reasons:
> [...]
> 
> No matter /how/ it's done, it needs /doing/. That's the crux of
> the matter.
> 
> Karsten
> -- 
> GPG key ID E4071346 @ wwwkeys.pgp.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
> 
> 
> ------------------------------
> 
> Date: Fri, 23 May 2003 16:12:27 +0200
> From: Karsten Hilbert <address@hidden>
> To: GNUmed list <address@hidden>
> Subject: [Gnumed-devel] gmDateTimeInput
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=us-ascii
> MIME-Version: 1.0
> Precedence: list
> Message: 8
> 
> I have committed a functional skeleton for date/time input
> widgets. If we start using them anywhere date/time input is
> needed we can transparently add features and have them show up
> in all places without any further coding (apart from the
> possible need for parameterization).
> 
> Currently this does not do anything wxTextCtrl can not do.
> However, the wxPython supplied date/time input widgets are not
> flexible enough (think: valid dates must be in the future but
> no more than 21 days, "+10" is to mean "add ten days" where
> "relative=1" means "to the currently displayed date" while
> "relative=0" means "to the initial default date" which may or
> may not be "today" depending on "default date" ... ;-)
> 
> Karsten
> -- 
> GPG key ID E4071346 @ wwwkeys.pgp.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
> 
> 
> ------------------------------
> 
> Date: Fri, 23 May 2003 16:41:33 +0200
> From: Karsten Hilbert <address@hidden>
> To: GNUmed list <address@hidden>
> Subject: Re: [Gnumed-devel] gmDateTimeInput
> Message-ID: <address@hidden>
> In-Reply-To: <address@hidden>
> References: <address@hidden>
> Content-Type: text/plain; charset=us-ascii
> MIME-Version: 1.0
> Precedence: list
> Message: 9
> 
> > I have committed a functional skeleton for date/time input
> > widgets. If we start using them anywhere date/time input is
> > needed we can transparently add features and have them show up
> > in all places without any further coding (apart from the
> > possible need for parameterization).
> And if you want to see it in action take a look at
> gmEditArea.gmAllergyEditArea._make_lines().
> 
> Karsten
> -- 
> GPG key ID E4071346 @ wwwkeys.pgp.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
> 
> 
> ------------------------------
> 
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnumed-devel
> 
> 
> End of Gnumed-devel Digest, Vol 6, Issue 35
> *******************************************