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