gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] HL7 data sample for you.


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] HL7 data sample for you.
Date: Wed, 2 Mar 2005 22:59:09 +0100
User-agent: Mutt/1.3.22.1i

> >Ian, do you think it an acceptable solution for now to add a
> >flag is_blob (or similar) to test_result
> IMHO display can be inferred by length.
Fine by me. I was just attempting to make some "concessions"
to "lure you into the trap" ;-)

> If it is a few chars, it can
> be displayed in Sebastian's grid-based viewer  (I'm assuming this
> was this original purpose.), if longer we need something else.
Sounds OK.

> The bigger issue with test_result is that it is poorly normalised.
You mean over-normalized ?

> So in an FBE, I can track the Hb, you can track the MCV, someone else can be 
> responsible for the WCC, and so on, which (to me) doesn't make any sense.
I see your point but I wonder whether that level of business
logic should really be enforced at the database level ?

Our widget allows for signing off groups, btw.

> My idea is for split viewer, with a listbox at the top listing the 
> transmissions.
> (so FBE such a date, U&E the next, and so on), when you click, it is shown:
> either a textbox for blobs, or the grid view for granular numeric results.
Well, this is what we would do with "profiles" - groupings of
related tests selectable to be shown together. Liz is working
on the clinical side therof.

> This implies *two* tables, one for tracking results (and a blobs field), and 
> one for granular numbers.
I should rather think the clean solution would be to
completely factor out status tracking from either of the two.
Which might eventually show that *all* clinical content should
have such tracking. Which just might result in it being folded
into clin_root_item at some point ...

> Maybe. AFAIK the only formats in use are ASCII (HL7 allows some basic 
> markup) and Word (which I would just pipe through "antiword" to return
> plain ASCII anyway)
I am fine with assuming everything to be ASCII. I do see how
HTML might come into play (eg generated from PIT).

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]