<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: News 7/28/10</title>
	<atom:link href="http://histalk2.com/2010/07/27/news-72810/feed/" rel="self" type="application/rss+xml" />
	<link>http://histalk2.com/2010/07/27/news-72810/</link>
	<description>Healthcare IT News and Opinion</description>
	<lastBuildDate>Wed, 23 May 2012 22:26:11 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3</generator>
	<item>
		<title>By: Soda Pop Man</title>
		<link>http://histalk2.com/2010/07/27/news-72810/comment-page-1/#comment-9967</link>
		<dc:creator>Soda Pop Man</dc:creator>
		<pubDate>Sat, 31 Jul 2010 21:57:00 +0000</pubDate>
		<guid isPermaLink="false">http://histalk2.com/2010/07/27/news-72810/#comment-9967</guid>
		<description>Lake Pointe Medical Center - nicely done!!! How fun!</description>
		<content:encoded><![CDATA[<p>Lake Pointe Medical Center &#8211; nicely done!!! How fun!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ruminating</title>
		<link>http://histalk2.com/2010/07/27/news-72810/comment-page-1/#comment-9953</link>
		<dc:creator>Ruminating</dc:creator>
		<pubDate>Thu, 29 Jul 2010 22:29:18 +0000</pubDate>
		<guid isPermaLink="false">http://histalk2.com/2010/07/27/news-72810/#comment-9953</guid>
		<description>Yes, I had overlooked the custom code against their existing data model, routines, etc.  That is another nightmare that would keep them from moving forward.

But, I still say - and you may still disagree - they can&#039;t stay on MUMPS forever.  It&#039;s just not a sustainable model.  Who else uses MUMPS, Cache or otherwise?  Not many.  They have to train their own engineers because it&#039;s not taught in any schools.  And most engineers want to work with the latest/greatest toolkit.  I mean, who wants to code in COBOL any more?

Just my .02</description>
		<content:encoded><![CDATA[<p>Yes, I had overlooked the custom code against their existing data model, routines, etc.  That is another nightmare that would keep them from moving forward.</p>
<p>But, I still say &#8211; and you may still disagree &#8211; they can&#8217;t stay on MUMPS forever.  It&#8217;s just not a sustainable model.  Who else uses MUMPS, Cache or otherwise?  Not many.  They have to train their own engineers because it&#8217;s not taught in any schools.  And most engineers want to work with the latest/greatest toolkit.  I mean, who wants to code in COBOL any more?</p>
<p>Just my .02</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: The Integrator</title>
		<link>http://histalk2.com/2010/07/27/news-72810/comment-page-1/#comment-9952</link>
		<dc:creator>The Integrator</dc:creator>
		<pubDate>Thu, 29 Jul 2010 22:02:20 +0000</pubDate>
		<guid isPermaLink="false">http://histalk2.com/2010/07/27/news-72810/#comment-9952</guid>
		<description>I iike how everyone talks about re-writing Epic. Attempting to re-write Epic from its present state to a different platform within any of our professional lifetimes would mean that they most likely would have to hire seasoned, experienced developers in whatever the &quot;new&quot; technology is in order to accomplish it.

As we all well know, Epic only hires people fresh from college (or is it high-school? I can&#039;t remember) to populate their castle. They eschew hiring any &quot;older people&quot; because we&#039;re a little less pliable at swilling the Kool-Aid or more likely - we have families, etc., and require something a little more than minimum wage. They don&#039;t allow telecommuting and require everyone to live no further than something like 30 to 45 minutes away from the mothership. Yep. Verona Wisconsin is a happenin place, woo hoo! (or is that, Moo Moo?)

They never embraced any of the more advanced Cache Objectscript coding methodologies - but quite frankly, they don&#039;t have to. 

People are still buying their product in droves, Judy Faulkner has learned how to try and make the sites rely less on certified consultants and more on new hires that can pass a multi-hour test (and still pay the uber $$$ for training - only now their incentive to train and work somewhere else is being taken away) and they are making money hand over fist.

Sure, there are sites whining about &quot;Epic should do _____&quot; and you know what? If Epic listens to you then be grateful. If not - tough.

Part of buying in to the homogenized &quot;one-size-fits-all&quot; suite with Epic means you have given up any leverage you ever had by working with multiple vendors trying to provide best-of-breed. You simplified your books by cutting one big check. Oh, and you probably spent so much on that first check that trying to swing enough cash to buy your way back into a best-of-breed situation wouldn&#039;t fly with the board. 

So any speculation about them enhancing, fixing, or converting their suite - sure, they might - but it will probably have less to do with any input from customers who have already signed their pact with the devil and more to do with their ultimate plan to dominate the universe.

Cheers!

The Integrator</description>
		<content:encoded><![CDATA[<p>I iike how everyone talks about re-writing Epic. Attempting to re-write Epic from its present state to a different platform within any of our professional lifetimes would mean that they most likely would have to hire seasoned, experienced developers in whatever the &#8220;new&#8221; technology is in order to accomplish it.</p>
<p>As we all well know, Epic only hires people fresh from college (or is it high-school? I can&#8217;t remember) to populate their castle. They eschew hiring any &#8220;older people&#8221; because we&#8217;re a little less pliable at swilling the Kool-Aid or more likely &#8211; we have families, etc., and require something a little more than minimum wage. They don&#8217;t allow telecommuting and require everyone to live no further than something like 30 to 45 minutes away from the mothership. Yep. Verona Wisconsin is a happenin place, woo hoo! (or is that, Moo Moo?)</p>
<p>They never embraced any of the more advanced Cache Objectscript coding methodologies &#8211; but quite frankly, they don&#8217;t have to. </p>
<p>People are still buying their product in droves, Judy Faulkner has learned how to try and make the sites rely less on certified consultants and more on new hires that can pass a multi-hour test (and still pay the uber $$$ for training &#8211; only now their incentive to train and work somewhere else is being taken away) and they are making money hand over fist.</p>
<p>Sure, there are sites whining about &#8220;Epic should do _____&#8221; and you know what? If Epic listens to you then be grateful. If not &#8211; tough.</p>
<p>Part of buying in to the homogenized &#8220;one-size-fits-all&#8221; suite with Epic means you have given up any leverage you ever had by working with multiple vendors trying to provide best-of-breed. You simplified your books by cutting one big check. Oh, and you probably spent so much on that first check that trying to swing enough cash to buy your way back into a best-of-breed situation wouldn&#8217;t fly with the board. </p>
<p>So any speculation about them enhancing, fixing, or converting their suite &#8211; sure, they might &#8211; but it will probably have less to do with any input from customers who have already signed their pact with the devil and more to do with their ultimate plan to dominate the universe.</p>
<p>Cheers!</p>
<p>The Integrator</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Cache$$$</title>
		<link>http://histalk2.com/2010/07/27/news-72810/comment-page-1/#comment-9946</link>
		<dc:creator>Cache$$$</dc:creator>
		<pubDate>Thu, 29 Jul 2010 15:56:02 +0000</pubDate>
		<guid isPermaLink="false">http://histalk2.com/2010/07/27/news-72810/#comment-9946</guid>
		<description>Blah Agreed - way too invested. What do you do with 2000+ developers, TS, and interface programmers that are proficient/experts at MUMPS. Not to mention the overhaul required in updating all training and release documentation. MUMPS it will be, Cache or otherwise. Anyone writing custom code does so at their own risk – any updates to code released from Epic and/or InterSystems cold potentially affect it.</description>
		<content:encoded><![CDATA[<p>Blah Agreed &#8211; way too invested. What do you do with 2000+ developers, TS, and interface programmers that are proficient/experts at MUMPS. Not to mention the overhaul required in updating all training and release documentation. MUMPS it will be, Cache or otherwise. Anyone writing custom code does so at their own risk – any updates to code released from Epic and/or InterSystems cold potentially affect it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Blah</title>
		<link>http://histalk2.com/2010/07/27/news-72810/comment-page-1/#comment-9943</link>
		<dc:creator>Blah</dc:creator>
		<pubDate>Thu, 29 Jul 2010 12:42:13 +0000</pubDate>
		<guid isPermaLink="false">http://histalk2.com/2010/07/27/news-72810/#comment-9943</guid>
		<description>Cache$$$ That&#039;s an interesting thought. Intersystems licensing is quiet frankly crazy. As a startup I can buy licenses from Intersystems for $100 each, but a large hospital who has tens of thousands of licenses pays $1000? Something is wrong there. If MSM was still out there and wasn&#039;t bought up by Intersystems to create a monopoly those prices would be far lower. However Cache is a decent product and EPIC would be well served removing the interpreted KBSQL and reduce the hardware costs due to the reduction of burden on the database. That in its self would help offset some of the licensing.

Ruminating, indeed. I would go as far as saying many years. It took over 10 years to get EPIC to this stage. The other side to that is EPIC allows customers to write custom code, within the framework of &quot;Programming points&quot; written in MUMPS. These may be business logic, reports, patient list information, HL7 overrides etc. How would they undo that work when moving to a different platform? It would certainly be difficult. Unfortunately even if they wanted to get out of MUMPS, they are too invested. And if they really were planning on getting out of the MUMPS game they would have stopped digging a deeper hole for themselves by giving customers new places to plug in M code, they haven&#039;t.</description>
		<content:encoded><![CDATA[<p>Cache$$$ That&#8217;s an interesting thought. Intersystems licensing is quiet frankly crazy. As a startup I can buy licenses from Intersystems for $100 each, but a large hospital who has tens of thousands of licenses pays $1000? Something is wrong there. If MSM was still out there and wasn&#8217;t bought up by Intersystems to create a monopoly those prices would be far lower. However Cache is a decent product and EPIC would be well served removing the interpreted KBSQL and reduce the hardware costs due to the reduction of burden on the database. That in its self would help offset some of the licensing.</p>
<p>Ruminating, indeed. I would go as far as saying many years. It took over 10 years to get EPIC to this stage. The other side to that is EPIC allows customers to write custom code, within the framework of &#8220;Programming points&#8221; written in MUMPS. These may be business logic, reports, patient list information, HL7 overrides etc. How would they undo that work when moving to a different platform? It would certainly be difficult. Unfortunately even if they wanted to get out of MUMPS, they are too invested. And if they really were planning on getting out of the MUMPS game they would have stopped digging a deeper hole for themselves by giving customers new places to plug in M code, they haven&#8217;t.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

