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: Thu, 3 Mar 2005 17:51:17 +0100
User-agent: Mutt/1.3.22.1i

> > > 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 thereof.
> I am actually talking about *transmissions*,
I know.

> which are a "natural" grouping provided by the path. lab, if you like.
They are not if you go by what a transmission may contain over
here. Suppose you ordered a bunch of tests which could be
assembled into two "natural" groups. Assuming some are
completed earlier than others and preliminary transmission
occurs inbetween we have no guarantee (spelling ?!?)
whatsoever that those that are transmitted are forming a
natural group.

> > > This implies *two* tables, one for tracking results (and a blobs field), 
> > > and 
> > Which might eventually show that *all* clinical content should
> yes.
> > have such tracking. Which just might result in it being folded
> > into clin_root_item at some point ...
> hmm, I'm not sure.
Notice the "just might". I am not at all convinced it should.

> If a path. result is entered out-of-hours by a cron
> daemon or e-mail listener, what episode and encounter does it have?
True enough. However, it could create an encounter - perfectly
valid as long as one doesn't think an encounter requires
personal interaction. As for episode it might link to an
episode "unreviewed inbox" forcing the reviewer to attach
results to a health problem (that is, an episode). Which
appears to make sense.

> (remember in AU we can't link back to the request)
I tend to forget that at times.

> > I am fine with assuming everything to be ASCII. I do see how
> > HTML might come into play (eg generated from PIT).
> Should be converted to ASCII IMHO.
Fine by me. Just trying to offer flexibility.

Note that I don't try to shoot down your improving of how
all this works. I think you are pretty much correct. I just
try to non-destructively re-schedule it's endeavour.

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]