| Contributors? [message #563287] |
Sun, 10 July 2005 01:40 |
 Jesse Kuhnert
Messages: 3
Registered: July 2009 |
Junior Member |
|
|
Having only scanned through the proposal documents that you guys have
generated I'm still a little unsure about what exactly it is that is
being built. It sounds like you want to build the whole system (which
would be very interesting, if not somewhat daunting..).
I'm interested in contributing something to the framework, it's just
hard to know how/where to do further research to see if there's anything
viable that I could provide.(ie where's the goods, or source if you will?)
I'm just a lowly engineer at an EMRS company that thought this
particular eclipse project looked pretty interesting. I have absolutely
no idea how I'll be able to justify contributing to it with my employer,
but over the past 5 years or so I think I've developed a fairly rich
framework that covers a very large spectrum of everything outlined in
your document. (We don't do everything..heh.., just the peri-operative
part.)
I guess that is the only stickler, as your document outlines, this is a
VERY competitive market, so how do I broach this with my employer? Maybe
~some~ things would be ok to work on and others not so much...
I wasn't sure if I saw it in the outline, but I was wondering if anyone
had discussed data dictionary / database persistence at all in the
discussions? I think out of all the things I've worked on and seen in
the industry, providing a better way to define these sort of "medical
terms" and how to access them in a standard SQL (or POJO) sort of way
would be nice...Much like projects based on http://protege.stanford.edu/
work. We have constructed our own data dictionary, complete with an
architecture to work with it, and I almost wanted to cry when I found
the above mentioned link at the end of the last product re-write phase
we went through..
Anyways, all of the things you guys outlined would be super cool and
all, but I think even cooler would be an additional component along the
lines of this data dictionary idea, as I think it's something EMRS
vendors would actually buy into and use, and might actually be able to
integrate into their existing products if it were designed well..We've
based our entire product architecture around this notion and it has
proven to be immeasurably helpful. Reports can be written and run in any
hospital now, billing rules are all universal(not universally used, but
the core logic can count on the same sort of data all the time..of
course drools helps us a lot too, even if it is a nasty codehaus.org
puke pile), etc etc..etc..Maybe my only contribution could be outputting
our dictionary in XML form for you, or sql, or whatever..
I hope extremely large rants that aren't well thought out before writing
each paragraph are ok here, just wanted to blurt out my initial feelings
and see if there is any code hiding away somewhere to go along with
this project.
PPS: Even better would be defining a universal "database" after having
defined the data dictionary. Then all the EMRS vendors could build their
product (as crappily or wonderfully as they want..ehh....) and the end
users won't be subjected to all manner of confusing technology choices
when it comes to at a very minnimum reviewing and analyzing data...And
of course this would very easily lead to the ultimate holy grial of
hospitals actually being able to share data ...But, much like the famous
movie quote(at least in my head) "there was once a dream that was rome,
one had only to mention it and it would all dissappear". Or something
like that. You know what I mean..
jesse
|
|
|
Powered by
FUDForum. Page generated in 0.03183 seconds
] 
Search
Help
Register
Login
Home
