[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.technology.ohf] Contributors?

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