<?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/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: PaaS Challenges for HIE Vendors</title>
	<atom:link href="http://chilmarkresearch.com/2009/11/03/paas-challenges-for-hie-vendors/feed/" rel="self" type="application/rss+xml" />
	<link>http://chilmarkresearch.com/2009/11/03/paas-challenges-for-hie-vendors/</link>
	<description>Providing perspective on key IT trends in the healthcare sector</description>
	<lastBuildDate>Thu, 09 Feb 2012 23:01:44 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: John</title>
		<link>http://chilmarkresearch.com/2009/11/03/paas-challenges-for-hie-vendors/#comment-3991</link>
		<dc:creator><![CDATA[John]]></dc:creator>
		<pubDate>Fri, 06 Nov 2009 22:54:06 +0000</pubDate>
		<guid isPermaLink="false">http://chilmarkresearch.com/?p=2113#comment-3991</guid>
		<description><![CDATA[Anand, thank you for your comment and inputs on future challenges.  

In 1 you quote salesforce.com which comes across to me as far too simplistic, certainly in healthcare where data models can be challenging to build, developing the appropriate taps to the data and least we forget, ensuring security of data flows.  This last point could get particularly tricky with new HIPAA guidelines and the move to consumer consent of data flow.

For number 2 I am in full agreement, though doubt if there will be any strong consensus among competing HIE vendors as to a common API that any 3rd party ISV can build to and then run their app on several different HIEs, regardless of the underlying HIE platform vendor.  Too many competing interests to make this work.  What will likely happen is some consolidation in the sector, clear leaders rising to the top (say 3-5), not an unreasonable number for an ISV to build for, esp if some HIE vendors, in desire to attract best apps, provide some seed funding/services to help ISV on-board to PaaS.

As to number 3, that is definitely a wild card and will be highly dependent on the company&#039;s leadership and culture.  This will not be an easy transition, many will not make it.

On another note, did get a comment via twitter where a VC guy saw the following 3 challenges as well:
1) Defining a new, profitable revenue model
2) Addressing potential channel/go to market conflicts
3) Scaling PaaS to address different data models.]]></description>
		<content:encoded><![CDATA[<p>Anand, thank you for your comment and inputs on future challenges.  </p>
<p>In 1 you quote salesforce.com which comes across to me as far too simplistic, certainly in healthcare where data models can be challenging to build, developing the appropriate taps to the data and least we forget, ensuring security of data flows.  This last point could get particularly tricky with new HIPAA guidelines and the move to consumer consent of data flow.</p>
<p>For number 2 I am in full agreement, though doubt if there will be any strong consensus among competing HIE vendors as to a common API that any 3rd party ISV can build to and then run their app on several different HIEs, regardless of the underlying HIE platform vendor.  Too many competing interests to make this work.  What will likely happen is some consolidation in the sector, clear leaders rising to the top (say 3-5), not an unreasonable number for an ISV to build for, esp if some HIE vendors, in desire to attract best apps, provide some seed funding/services to help ISV on-board to PaaS.</p>
<p>As to number 3, that is definitely a wild card and will be highly dependent on the company&#8217;s leadership and culture.  This will not be an easy transition, many will not make it.</p>
<p>On another note, did get a comment via twitter where a VC guy saw the following 3 challenges as well:<br />
1) Defining a new, profitable revenue model<br />
2) Addressing potential channel/go to market conflicts<br />
3) Scaling PaaS to address different data models.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Paul Roemer</title>
		<link>http://chilmarkresearch.com/2009/11/03/paas-challenges-for-hie-vendors/#comment-3984</link>
		<dc:creator><![CDATA[Paul Roemer]]></dc:creator>
		<pubDate>Fri, 06 Nov 2009 00:48:27 +0000</pubDate>
		<guid isPermaLink="false">http://chilmarkresearch.com/?p=2113#comment-3984</guid>
		<description><![CDATA[Great point John.  I think you couple PaaS and SaaS, shrink wrap, and help providers define their requirements and apply for the ARRA money and that&#039;s something they can live with.

Better yet, &quot;lend&quot; them the ARRA money up front.]]></description>
		<content:encoded><![CDATA[<p>Great point John.  I think you couple PaaS and SaaS, shrink wrap, and help providers define their requirements and apply for the ARRA money and that&#8217;s something they can live with.</p>
<p>Better yet, &#8220;lend&#8221; them the ARRA money up front.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Anand Shroff</title>
		<link>http://chilmarkresearch.com/2009/11/03/paas-challenges-for-hie-vendors/#comment-3983</link>
		<dc:creator><![CDATA[Anand Shroff]]></dc:creator>
		<pubDate>Thu, 05 Nov 2009 17:32:22 +0000</pubDate>
		<guid isPermaLink="false">http://chilmarkresearch.com/?p=2113#comment-3983</guid>
		<description><![CDATA[John,

Agree with your points here. Additionally -

1. On the architecture front, the key will be to select and expose appropriate service points to build a true platform. From the salesforce.com website - &quot;It (PaaS) is delivered in the same way as a utility like electricity or water. Users simply “tap in” and take what they need without worrying about the complexity behind the scenes.&quot; (http://www.salesforce.com/paas/) What &quot;taps&quot; will the HIE vendor expose? 

2. Standards - if there are available standards for specific types of services, ISVs would be more interested in building apps to those services since the app will then be portable to multiple platforms. I think this will require collaboration between HIE vendors and motivated ISVs to develop these standards. This is a significant hurdle to overcome.

3. Business model - if an HIE vendor supports and exposes PaaS, what is the impact to their business? Traditionally the approach has been to build all applications that customers require (albeit not all that successfully) thus theoretically keeping a larger share of the revenues. By enabling ISVs to build applications, the HIE vendor will keep (at least superficially) a lower portion of the revenues.

Very interesting discussion, and hopefully we&#039;ll see continued evolution in this area.

Thanks,
Anand Shroff
VP, Products @ Axolotl]]></description>
		<content:encoded><![CDATA[<p>John,</p>
<p>Agree with your points here. Additionally -</p>
<p>1. On the architecture front, the key will be to select and expose appropriate service points to build a true platform. From the salesforce.com website &#8211; &#8220;It (PaaS) is delivered in the same way as a utility like electricity or water. Users simply “tap in” and take what they need without worrying about the complexity behind the scenes.&#8221; (<a href="http://www.salesforce.com/paas/" rel="nofollow">http://www.salesforce.com/paas/</a>) What &#8220;taps&#8221; will the HIE vendor expose? </p>
<p>2. Standards &#8211; if there are available standards for specific types of services, ISVs would be more interested in building apps to those services since the app will then be portable to multiple platforms. I think this will require collaboration between HIE vendors and motivated ISVs to develop these standards. This is a significant hurdle to overcome.</p>
<p>3. Business model &#8211; if an HIE vendor supports and exposes PaaS, what is the impact to their business? Traditionally the approach has been to build all applications that customers require (albeit not all that successfully) thus theoretically keeping a larger share of the revenues. By enabling ISVs to build applications, the HIE vendor will keep (at least superficially) a lower portion of the revenues.</p>
<p>Very interesting discussion, and hopefully we&#8217;ll see continued evolution in this area.</p>
<p>Thanks,<br />
Anand Shroff<br />
VP, Products @ Axolotl</p>
]]></content:encoded>
	</item>
</channel>
</rss>

