[Top][All Lists]
[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
- Re: [Gnumed-devel] lab data fetcher/importer connection methods, catmat, 2005/03/01
- [Gnumed-devel] HL7 data sample for you., Richard Terry, 2005/03/01
- Re: [Gnumed-devel] HL7 data sample for you., Horst Herb, 2005/03/01
- Re: [Gnumed-devel] HL7 data sample for you., Ian Haywood, 2005/03/01
- Re: [Gnumed-devel] HL7 data sample for you., Karsten Hilbert, 2005/03/02
- Re: [Gnumed-devel] HL7 data sample for you., Ian Haywood, 2005/03/02
- Re: [Gnumed-devel] HL7 data sample for you.,
Karsten Hilbert <=
- Re: [Gnumed-devel] HL7 data sample for you., Ian Haywood, 2005/03/03
- Re: [Gnumed-devel] HL7 data sample for you., Karsten Hilbert, 2005/03/03
- Re: [Gnumed-devel] HL7 data sample for you., Ian Haywood, 2005/03/03
- Re: [Gnumed-devel] HL7 data sample for you., Karsten Hilbert, 2005/03/03
- Re: [Gnumed-devel] HL7 data sample for you., Ian Haywood, 2005/03/03
- Re: [Gnumed-devel] HL7 data sample for you., J Busser, 2005/03/03
- Re: [Gnumed-devel] HL7 data sample for you., Karsten Hilbert, 2005/03/03
- Re: [Gnumed-devel] HL7 data sample for you., Karsten Hilbert, 2005/03/03
- Re: [Gnumed-devel] HL7 data sample for you., J Busser, 2005/03/04
- Re: [Gnumed-devel] HL7 data sample for you., E Dodd, 2005/03/04