Re: [Gnumed-devel] re : experimental editor

[Karsten Hilbert]

> but things have moved on  , and  K has decided to obsolete the code 
> that was done , AFAIK.
I have to decided to not use it except for drawing ideas
(which I did believe it or not). I can't obsolete it. This is
GNU, as you said.

> There is also currently a SOAP attribute that cuts 
> across all clin_root_items,
> even those of clin_history, clin_physical and clin_working_diagnosis
And which obsoletes the need for clin_history/clin_physical.
They can be folded into clin_narrative with soap_cat=...
This will rid us of the ability to record data sources but I
am not sure we'll need it. And we can add it again later.

> part of S, O, and A respectively, and I suppose this leaves vaccination  
> , which is almost always P,
Which is why there's a default 'p' on that table.

> clin_note and clin_aux_note, which are the only 2 subclasses of 
> clin_root_item that would seem to need
clin_note has been expanded to be clin_narrative, the type of
narrative being declared by soap_cat. clin_aux_note should be
used sparingly for when a table *really* needs one more
narrative field.

> the SOAP attribute mandatorily).  Where in the current schema do actions 
> such as ordering investigations,
> and prescribing go ?
Nowhere yet at all.

Oh, ordering lab work goes in lab_request.

Some work on storing referral orders is being done by Ian.

> Artefacts produced from clin_root_items that are 'objective' - 
> clin_physical , lab_request -
> can be stored in  test_result  -  N.B. even quantitative physical 
> findings, are a form of test_result, e.g. BP measurement, thermometer 
> reading.
Sure, quantifyable findings should be stored in test_result.

> This structure seems good enough to hold everything except the script 
> prescription, and procedures.
What does "procedures" encompass ?

> With clin_episode, the main reason I can see for it's existence is that 
> it makes it easy to shift a whole lot of
> different clin_root_items attached to it from one health issue to 
> another, so it provides the ability to deal
> with a problem when the actual health_issue is not defined yet, but will 
> be over time.
That is the technical reason. The medical reason is that it
sorts data according to clinical episodes.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346