<?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: Medical Device Software on Shared Computers</title>
	<atom:link href="http://rdn-consulting.com/blog/2009/09/07/medical-device-software-on-shared-computers/feed/" rel="self" type="application/rss+xml" />
	<link>http://rdn-consulting.com/blog/2009/09/07/medical-device-software-on-shared-computers/</link>
	<description>Software Development and Biomedical Engineering</description>
	<lastBuildDate>Sun, 14 Mar 2010 01:04:43 -0500</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: PeteMac</title>
		<link>http://rdn-consulting.com/blog/2009/09/07/medical-device-software-on-shared-computers/comment-page-1/#comment-2054</link>
		<dc:creator>PeteMac</dc:creator>
		<pubDate>Mon, 14 Sep 2009 07:01:05 +0000</pubDate>
		<guid isPermaLink="false">http://rdn-consulting.com/blog/?p=297#comment-2054</guid>
		<description>@Steve:

&quot;No shared access issues&quot;! Fantastic. This is absolutely the best solution - from your point of view and your convenience as a manufacturer. But what about us, the users? We would end up with 20 PCs at the bedside - one from you, one from GE, one from Philips, one from... well, you get the idea. 

Grow up and move on with the times, Steve. Your strategy of &quot;we control what is done with our system&quot; would work only if you were the only supplier of &quot;software devices&quot; in the hospital. Maybe you do have grandiose dreams of being in such a priviledged position, but unfortunately, when you wake up from your delusional dreams, you will find that customers are not sheep - they do pick and choose the best systems and devices from different vendors.

If you stick with the pre-historic strategy of having &quot;No shared access issues&quot; because you, infact, have no shared access - your products will end up in the reject pile at our next evaluation. I promise you that. Your arrogant tone in this post has motivated me to make the resolution that I will use whatever influence I have with NHS to make sure that, in the future, interoperability and co-existance of medical applications will become one of the core criteria for choosing such systems in UK. Then, I&#039;m sure, you will discover all sorts of new strategies, like how Philips has finally done with their xds application (which I always cite as an example, not because I am so partial to Philips, but because, unfortunately, it seems to be the only such product in the market).</description>
		<content:encoded><![CDATA[<p>@Steve:</p>
<p>&#8220;No shared access issues&#8221;! Fantastic. This is absolutely the best solution &#8211; from your point of view and your convenience as a manufacturer. But what about us, the users? We would end up with 20 PCs at the bedside &#8211; one from you, one from GE, one from Philips, one from&#8230; well, you get the idea. </p>
<p>Grow up and move on with the times, Steve. Your strategy of &#8220;we control what is done with our system&#8221; would work only if you were the only supplier of &#8220;software devices&#8221; in the hospital. Maybe you do have grandiose dreams of being in such a priviledged position, but unfortunately, when you wake up from your delusional dreams, you will find that customers are not sheep &#8211; they do pick and choose the best systems and devices from different vendors.</p>
<p>If you stick with the pre-historic strategy of having &#8220;No shared access issues&#8221; because you, infact, have no shared access &#8211; your products will end up in the reject pile at our next evaluation. I promise you that. Your arrogant tone in this post has motivated me to make the resolution that I will use whatever influence I have with NHS to make sure that, in the future, interoperability and co-existance of medical applications will become one of the core criteria for choosing such systems in UK. Then, I&#8217;m sure, you will discover all sorts of new strategies, like how Philips has finally done with their xds application (which I always cite as an example, not because I am so partial to Philips, but because, unfortunately, it seems to be the only such product in the market).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: A .NET Application that Never Dies &#124; Bob on Medical Device Software</title>
		<link>http://rdn-consulting.com/blog/2009/09/07/medical-device-software-on-shared-computers/comment-page-1/#comment-2047</link>
		<dc:creator>A .NET Application that Never Dies &#124; Bob on Medical Device Software</dc:creator>
		<pubDate>Sat, 12 Sep 2009 21:08:54 +0000</pubDate>
		<guid isPermaLink="false">http://rdn-consulting.com/blog/?p=297#comment-2047</guid>
		<description>[...] About            &#171; Medical Device Software on Shared Computers [...]</description>
		<content:encoded><![CDATA[<p>[...] About            &laquo; Medical Device Software on Shared Computers [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steve</title>
		<link>http://rdn-consulting.com/blog/2009/09/07/medical-device-software-on-shared-computers/comment-page-1/#comment-2044</link>
		<dc:creator>Steve</dc:creator>
		<pubDate>Thu, 10 Sep 2009 14:18:43 +0000</pubDate>
		<guid isPermaLink="false">http://rdn-consulting.com/blog/?p=297#comment-2044</guid>
		<description>Thats why we ship our product with WindowsXP Embedded and we control what is done with our system.  No shared access issues.</description>
		<content:encoded><![CDATA[<p>Thats why we ship our product with WindowsXP Embedded and we control what is done with our system.  No shared access issues.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: PeteMac</title>
		<link>http://rdn-consulting.com/blog/2009/09/07/medical-device-software-on-shared-computers/comment-page-1/#comment-2043</link>
		<dc:creator>PeteMac</dc:creator>
		<pubDate>Wed, 09 Sep 2009 07:45:47 +0000</pubDate>
		<guid isPermaLink="false">http://rdn-consulting.com/blog/?p=297#comment-2043</guid>
		<description>Dear Bob,

What is required is for the &quot;software device&quot; manufacturers to:
a. write applications that are designed from ground up to be good IT citizens
b. test and understand the processing and bandwidth requirements for the application
c. test the application in conjunction with other applications running simultaneously at different I/O bandwidth, processor bandwidth levels and discover the vulnerabilities
d. provide a diagnostic test that can be run each time the PC environment is changed, to ensure the application still works properly. If it doesn&#039;t, then &quot;spec up&quot; the PC or remove the last application.

You may also wish to read my comments on Tim Gee&#039;s Medical Connectivity blog. I do sincerely apologize for the statement on the penultimate comment, when I thought you had removed Konrad W&#039;s reply.

I don&#039;t think blindly spreading panic based on unfounded belief systems are good for the advancement of technology that people like I have been waiting for a very very long time. I still hope to see it happen during the few years I have left in my (working) life.</description>
		<content:encoded><![CDATA[<p>Dear Bob,</p>
<p>What is required is for the &#8220;software device&#8221; manufacturers to:<br />
a. write applications that are designed from ground up to be good IT citizens<br />
b. test and understand the processing and bandwidth requirements for the application<br />
c. test the application in conjunction with other applications running simultaneously at different I/O bandwidth, processor bandwidth levels and discover the vulnerabilities<br />
d. provide a diagnostic test that can be run each time the PC environment is changed, to ensure the application still works properly. If it doesn&#8217;t, then &#8220;spec up&#8221; the PC or remove the last application.</p>
<p>You may also wish to read my comments on Tim Gee&#8217;s Medical Connectivity blog. I do sincerely apologize for the statement on the penultimate comment, when I thought you had removed Konrad W&#8217;s reply.</p>
<p>I don&#8217;t think blindly spreading panic based on unfounded belief systems are good for the advancement of technology that people like I have been waiting for a very very long time. I still hope to see it happen during the few years I have left in my (working) life.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bob</title>
		<link>http://rdn-consulting.com/blog/2009/09/07/medical-device-software-on-shared-computers/comment-page-1/#comment-2041</link>
		<dc:creator>Bob</dc:creator>
		<pubDate>Tue, 08 Sep 2009 15:48:28 +0000</pubDate>
		<guid isPermaLink="false">http://rdn-consulting.com/blog/?p=297#comment-2041</guid>
		<description>@Konrad W I agree that most of today’s consumer-grade PCs are very capable of handling high bandwidth I/O and processing tasks. As you say, all you need to do is &quot;spec the device&quot;. But that’s where the problem lays when you’re sharing the system. Even if the PC and OS are capable of handling your task(s), what happens when the user installs other applications that double or even triple the bandwidth and processing requirements? At some point the device will not be able to handle it.</description>
		<content:encoded><![CDATA[<p>@Konrad W I agree that most of today’s consumer-grade PCs are very capable of handling high bandwidth I/O and processing tasks. As you say, all you need to do is &#8220;spec the device&#8221;. But that’s where the problem lays when you’re sharing the system. Even if the PC and OS are capable of handling your task(s), what happens when the user installs other applications that double or even triple the bandwidth and processing requirements? At some point the device will not be able to handle it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Konrad W</title>
		<link>http://rdn-consulting.com/blog/2009/09/07/medical-device-software-on-shared-computers/comment-page-1/#comment-2039</link>
		<dc:creator>Konrad W</dc:creator>
		<pubDate>Tue, 08 Sep 2009 08:11:00 +0000</pubDate>
		<guid isPermaLink="false">http://rdn-consulting.com/blog/?p=297#comment-2039</guid>
		<description>&quot;With today’s PC architectures, the highest risk area is at the device driver level. Running multiple devices that require even modest I/O bandwidth can cause interference that could result in lost or significantly delayed data. This is especially true with Windows XP or Vista that do not inherently provide any real-time data processing capabilities.&quot;

Bob, where on earth are you getting your information from? This might have been true for my granddad&#039;s PC XT, but not anymore. My company designs industrial control systems on embedded Win XP and on Server 2003 that handle multiple (up to 32)simultaneous data streams via serial port concentrators. You just need to spec the device to the level where it can handle it.</description>
		<content:encoded><![CDATA[<p>&#8220;With today’s PC architectures, the highest risk area is at the device driver level. Running multiple devices that require even modest I/O bandwidth can cause interference that could result in lost or significantly delayed data. This is especially true with Windows XP or Vista that do not inherently provide any real-time data processing capabilities.&#8221;</p>
<p>Bob, where on earth are you getting your information from? This might have been true for my granddad&#8217;s PC XT, but not anymore. My company designs industrial control systems on embedded Win XP and on Server 2003 that handle multiple (up to 32)simultaneous data streams via serial port concentrators. You just need to spec the device to the level where it can handle it.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
