Re: [Gnumed-devel] clin_root_item

[Ian Haywood]

On Sun, 26 Oct 2003 12:13:49 +1100
syan tan <address@hidden> wrote:

> At the moment, I was thinking of yamilizing user input, into one text 
> field, and then putting it on a clin_root_item.
The problem is the entered information in each editarea needs to be 
entered into different tables, which descend from clin_root_item
(most of which haven't been written yet!)

Again we are seeing the problem that gnumed is being built backwards,
we have a finished GUI, but incomplete business logic and database schemas.

The reason i don't like this is I don't want clinical data wrapped up in YAML 
in text fields, this closes
off a lot of options.

The power of SQL is that we can ask the database questions like
"how many patients over 65 have diabetes?" "which patients
are overdue for their Pap smear?" *across* multiple patients and times.
This is impossible (or impossibly slow)
if the data is wrapped u in YAML/XML or similar.
 
> e.g. I'm using clin_history with type = 2( past)  and storing it on the 
> narrative field.
> should there be a special field , or cross-referenced table for 
> application-specific input data ?
> (e.g. with fields like   application_name,  schema_url, version,  data, 
> application_data_path , id_clin_root_item)

> There are 9 types of editareas ,
> 3 of them could be actions ( recall, referral, request) producing some 
> other data item
>     ( but it would be nice to store the input on these , so actions can 
> be modified and repeated).
true.
> family_history can be mapped to clin_history with a different type,
yes
> allery mapped to mapped to allergy
> vaccination mapped to vaccination
> prescription to prescription
Yes, but prescription has *lots* of actions, probably the most complex
(think a good ~50 lines of Python code interacting with various business 
objects)
> ? what about measurement.
can't think of any actions here, but needs to be able to query quickly across
numerous clinical entries to draw graphs of blood results etc. 9see above)

Ian
-- 
PGP public key E750652E at wwwkeys.pgp.net
9BF0 67B7 F84F F7EE 0C42  C063 28FC BC52 E750 652E