‘tightly coupled’ and ‘loosely coupled’ is the big deal here. everything else is dull details. It is why meditech has a retention rate and overpriced software. the rest of the IS world has moved on to better architectures. Even the biggest dogs are starting to realize that enterprise integrated systems are not the way to go. but for most hospitals, moving on is cost prohibitive unless you bring in programming talent that is still expensive and a high risk due to the difficulty of measuring talent in the interview process.

people are smearing meditech because when they realize this, they feel like they are being taken advantage of… and they are.

In general – quit standing on your floating ice patch defending the water. in another 10 years all systems will evolve to a master data system architecture with a SOA layer, a data dictionary, and business rules management with a generic front-end. Its inevitable, and much cheaper.

in the meantime – I have to spend hours figuring out how to code in meditech so I can make an interface that would normally cost $10,000 plus maintenance… (a two hour affair in any present day coding architecture) then after that I have to build an NPR report that will do the cost containment report because I couldn’t get anyone on the phone at meditech that new how to get their standard report to work correctly. In the mean time, I have to try to look through source code so I can find functions in this ‘open’ language… because when I asked meditech for info on programming – they said ‘get a job at meditech’. pretty smug, no?

and if you think i am going to spend millions of dollars moving to 6.0 — with no migration plan — and integration costs that include consulting bills because I can’t pull folks off the floor to build… well i think you can see how absurd that is.

Just my two cents, two years late. I hope you all open your minds a bit and realize that if we don’t demand change, we will continue to be locked into mediocrity. We need to join together to continue the progress of architectures that increase efficiencies, ROI, and security… or at least bring in the latest Information System best practices from other fields… not spending hours defending last decade’s technology.

I’m not entirely sure what you are talking about, but I’m pretty confident the answer is no.

As for the language incompatibility, does this mean that Magic and FS will still store data in a similar way? IE can I layer the new app code on top of my old array without changing the data structure?

Sorry if I’m talking GT.M/Cache talk, it’s what I am most familiar with.

No one has denied the MUMPS – MIIS – Magic genealogy. What he, and I, have said is that they’re not the same language.

By the way, there is no compatibility between Magic and FS.