[news.eclipse.technology.ohf] Re: Contributors?

["Brian Barry" <brian@xxxxxxxxxxx>]

Thanks for the post.  Let me begin by saying that the proposal is
deliberately fluid to allow room for others to play, which is a polite way
of saying that we haven't really worked out all the details<grin>.  The bad
news is it's hard to answer detailed questions like yours; the good news
that you can help construct the answer.

So let me try for at least a few answers.

>>It sounds like you want to build the whole system
Yep that's it..it is clearly a very ambitious undertaking.  But our feeling
is that only by providing a common ubiquitous platform that everyone can use
to build on can we really crack the interoperability problems.  No doubt
this is a large multi-year project, and it might not work out -- but then
most things worth doing (including the Eclipse Platform) start that way.

>>where's the goods, or source if you will
You're ahead of us I'm afraid, right now we're at the proposal stage,
assuming we clear that then we will over time begin to populate the site
with plan info and then early code drops. But realistically we're a few
months away from that. On the other hand if you have code you're willing to
contribute this would be a *really* good time to put it on the table as a
possibility.

>>I've developed a fairly rich framework that covers a very large spectrum
Is there any overview doc you can make available? That would help to make
the discussion more tangible. In terms of convincing your employer, everyone
has to make their own call on that.  In my experience most companies get
involved because they see the open source train coming and decide it's
better to be on the train than on the tracks<grin>.

>>discussed data dictionary / database persistence at all in the discussions
Sure it shows up in several places; if you look at the architecture
diagram/description, record storage, terminology service, and archetypes all
are aspects of the persistence discussion.  I'll see if I can prompt some of
the folks who have expertise in that area to post on this thread.

"Jesse Kuhnert" <jkuhnert@xxxxxxxxxxxxxx> wrote in message
news:dapu8o$a2u$1@xxxxxxxxxxxxxxxxxxx
> 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