gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Forms and lab requests - RICHARD'S COMMENTS


From: richard terry
Subject: Re: [Gnumed-devel] Forms and lab requests - RICHARD'S COMMENTS
Date: Tue, 27 Apr 2004 14:21:45 +1000
User-agent: Mozilla Thunderbird 0.5 (X11/20040303)

Sorry, have been away on holidays, now sifting through 1132 emails (1 week!) or which nearly 40% were spam.

Not quite sure what you mean by 'pending request'. I presume you mean a request you have ordered for which the result is not yet back?

As a concept - in my schema it is irrevent what the request is, as all types are treated identically - ie it matters not if one is requesting physio, bone density, pathology, radiology, podiatry service, vascular investigations, etc etc.

All are presented the same way and saved the same way in the database.  I've not included field types unless not obvious.

Everything is seen in terms of a 'request form' which contains one or more requests.
The tests requested are displayed in the tabbed lists and can be viewed as a form (with aggregated tests e.g FBC;UEC:MSU) or sorted and listed according to date/test type etc - see the printed docs).

As all tests are handled the same way they are also printed the same way on plain paper request form.

Hope this helps.

------------------------------------
Data_Requests_Forms
------------------------------------
Form_ID
Consult_ID
Type_ID
Notes_ID (notes user types on form)
Deleted
REquests_Summary (used for display purposes)
Organisation_ID (key to provider of service)
-----------------------------------------------
Data_Requests_Forms_Notes
-----------------------------------------------
ID (Key to Notes_ID in Data_Requests_Forms) - not kept as patient specific
Notes (text 255)
----------------------------------------------------
Data_Requests_Forms_Requests
----------------------------------------------------
Record_ID (autonumber)
Form_ID
Request_ID
Provider_ID
Deleted
------------------------------
Request_lu_Names
------------------------------
Request_ID (autonumber)
Provider_Type_ID (eg 1 = pathology 2 = radiology 3 = physio etc etc)
Section_ID  (I used for subsection of the above eg u/s xray, CT - but never really used this splitdown capability)
Name_ID (I used to point to Hunter Pathology internal test ID)
Description (eg msu)
Descision_Support_ID (pointer to file if decision support for test available)
Lateralisation (1=left 2 =right 3 =both) ie test displays as Xray Femur (left) etc
-----------------------------
Request_lu_Sections
---------------------------------
see comment above
---------------------------
Request_lu_Type
---------------------------
Request_Type_ID (eg 1= pathology)
Description (eg pathology)
Memo

Karsten Hilbert wrote:
I note the inclusion of a VO for lab requests.
Does that mean separate VOs for radiology requests, allied health
requests, medical referrals etc. I have no objection in principle, but
I'm not sure how we would present this in the GUI, the number of
editareas (if we have one for each) would soon get out of control.
    

Hm, the thing is I am currently working on getting lab results
handling working with GnuMed. Reason being that my parents
need that today. A Lab Request makes clinical sense to me. I
didn't see any *immediately obvious* way of generalizing the
request class to any kind of request (one would then have to
draw a line on much murkier grounds). I do understand the
possible benefit of it, though. When I or someone else gets
around to actually writing the code for a particular use case of
another kind of request we might discover: "Hey, it makes a
lot of sense to generalize things like *this*." We'd then
refactor. I hope to have the *type* of API stable enough to
allow for that.

Yes, it could also mean we are going to have several request
classes. I don't really fear that much proliferation since I
am not observing that many types of requests in daily work,
maybe 5 or so.

BTW, I plan on at least two "ways" of entering pending
requests (sharing the code, of course): One for it being
called from the macro processor (think by a controlling
legacy app), the other by going to to a "lab journal" notebook
plugin.

Richard, how did you handle lab data in your client
especially the pending request input side of things ?

Ian, does that help any ? (BTW, what is an allied health
request ?)

Karsten
  


reply via email to

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