<?xml version="1.0" encoding="UTF-8"?>
<!-- generator="wordpress/2.3.3" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>

<channel>
	<title>Medical Connectivity &#187; Wireless Medical Devices</title>
	<link>http://medicalconnectivity.com</link>
	<description></description>
	<pubDate>Wed, 21 Apr 2010 17:56:36 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3.3</generator>
	<language>en</language>
			<item>
		<title>FCC Seeks Comment (Again) on MBANs</title>
		<link>http://medicalconnectivity.com/2009/09/23/fcc-seeks-comment-again-on-mbans/</link>
		<comments>http://medicalconnectivity.com/2009/09/23/fcc-seeks-comment-again-on-mbans/#comments</comments>
		<pubDate>Thu, 24 Sep 2009 05:48:34 +0000</pubDate>
		<dc:creator>Tim Gee</dc:creator>
		
		<category><![CDATA[Standards &amp; Regulatory]]></category>

		<category><![CDATA[Wireless Medical Devices]]></category>

		<guid isPermaLink="false">http://medicalconnectivity.com/2009/09/23/fcc-seeks-comment-again-on-mbans/</guid>
		<description><![CDATA[The same vague promises of working out an industry standard after the fact were made when WMTS was created.]]></description>
			<content:encoded><![CDATA[<p>Some semi recent news on Medical Body Area Networks (MBANs) from GE Research and the FCC. It starts with GE&#8217;s September 1, 2009 <a href="http://finance.yahoo.com/news/GE-Working-to-Enable-a-bw-2893053253.html?x=0&amp;.v=1">press release</a> (pdf), where they announced:</p>
<blockquote><p>&#8230;an intiative aimed to develop wireless medical monitoring systems, or body sensor networks (BSN), which would replace the traditional tangle of bedside caables used to capture a patient&#8217;s vital signs. GE&#8217;s vision for the systems would enable wireless monitoring from anywhere in the hospital &#8212; or even remotely at home.</p></blockquote>
<p>For the past couple years, GE&#8217;s been pushing for the allocation of spectrum for MBANs. The press release notes that, &#8220;The FCC recently issued a notice of proposed rulemaking (NPRM), acting upon GE Healthcare’s petition to establish a new, vendor-neutral dedicated radio frequency band for low-power, short-range, wireless patient monitoring devices. This petition requested creation of a new Medical Body Area Network Service (MBANS), to support wireless sensors that monitor a patient’s health state, linked together in body sensor networks.&#8221;</p>
<p>Here&#8217;s David Davenport talking about their wireless sensor initiative:</p>
<p><object width="320" height="265">
<param name="movie" value="http://www.youtube.com/v/K15f1MqB-8U&#038;hl=en&#038;fs=1&#038;rel=0"></param>
<param name="allowFullScreen" value="true"></param>
<param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/K15f1MqB-8U&#038;hl=en&#038;fs=1&#038;rel=0" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="320" height="265"></embed></object></p>
<p>Apparently, GE&#8217;s going after the cable replacement business for traditional multi parameter patient monitors. <a href="http://www.lifesynccorp.com/">LifeSync</a> has had a product replacing ECG cables (by far the most predominate type of cables in clinical use) for several years. LifeSync also controls the <a href="http://www.google.com/patents/about?id=SH0IAAAAEBAJ&amp;dq=besson+bax+patent+wireless">Besson patent </a>(licensed to them exclusively by Motorola) that applies to wireless sensor based physiological monitoring.The <a href="http://www.fcc.gov/Daily_Releases/Daily_Business/2009/db0629/DOC-291783A1.txt">FCC Notice of Proposed Rulemaking</a> referenced is from June 29, 2009. Another &#8220;<a href="http://www.martindale.com/communications-law/article_Bingham-McCutchen-LLP_421998.htm">article</a>&#8221; written by a law firm apparently engaged by GE was published March 20, 2009 and outlines:</p>
<blockquote><p><strong>Proposed Frequency Band:</strong>  &#8221;identified the 2360-2400 MHz band as the preferred frequency band based on engineering studies showing that MBANS devices can successfully coexist with incumbent operators and users.&#8221; I would love to see that coexistence data. In a conversation with David Davenport of GE Global Research that, he told me that spectrum just outside 2.4 GHz was desired because it would enable the use of off the shelf 2.4 GHz components, with only minimal modifications. <a href="http://medicalconnectivity.com/2009/09/23/fcc-seeks-comment-again-on-mbans/#more-1269" class="more-link">(more&#8230;)</a></p>
]]></content:encoded>
			<wfw:commentRss>http://medicalconnectivity.com/2009/09/23/fcc-seeks-comment-again-on-mbans/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Medical Device System Network Install Issues</title>
		<link>http://medicalconnectivity.com/2009/09/22/medical-device-system-networking-issues/</link>
		<comments>http://medicalconnectivity.com/2009/09/22/medical-device-system-networking-issues/#comments</comments>
		<pubDate>Tue, 22 Sep 2009 16:37:19 +0000</pubDate>
		<dc:creator>Tim Gee</dc:creator>
		
		<category><![CDATA[Healthcare IT]]></category>

		<category><![CDATA[Standards &amp; Regulatory]]></category>

		<category><![CDATA[Uncategorized]]></category>

		<category><![CDATA[Wireless Medical Devices]]></category>

		<guid isPermaLink="false">http://medicalconnectivity.com/2009/09/22/medical-device-system-networking-issues/</guid>
		<description><![CDATA[If a medical device system runs on a network (physically separate or as a VLAN on your hospital enterprise network) the network is part of the medical device.]]></description>
			<content:encoded><![CDATA[<p>Last week there was an interesting discussion on the Biomed Listserv about network installation for patient monitoring systems. Emphasis highlighting key issues and best practices are mine. The discussion started with a question from Scott Skinner:</p>
<blockquote><p>I&#8217;m curious if anyone has been successful using their own vendors to pull cables for monitoring installations.  With the monitoring OEM we work with, they simply get a local subcontractor to do the cable pulls.</p>
<p>So this would involve breaking future monitoring packages up into two quotes:  one for the actual technology itself (and associated installation and implementation), and then one for just the cable pull work.  The latter would get bid out, and the OEM could compete against other vendors.</p>
<p>Of course, the OEM can just take the profit they would have made on the cable pull and add that to the cost of the equipment bid.  One would need to find a way to watch that carefully.</p></blockquote>
<p>Which lead to a critical observation from Craig Muehling:</p>
<blockquote><p>We have started pulling our own cable for monitoring installations. I have one happening now and I&#8217;m not exactly pleased how it&#8217;s working out. I won&#8217;t mention and names, [vendor name removed] but they make their equipment charges per drop whether you have any drops or not.</p>
<p>I would still like our [networking] vendor to do the networking, ie: install and configure switches and physically plug patch cables into the switches. Seems easy, but the way they [the patient monitoring vendor] charge it&#8217;s really not much less than if they did the whole job. I think from now on, we will have to take on the entire networking job.</p>
<p>I have learned a lesson from this last installation and will scrutinize the quotes closer from now on, but with their charging structure<br />
(supposedly) there&#8217;s not a lot of options. Either we do the entire job, or they make lots and lots of money for relatively little work.</p></blockquote>
<p>Here&#8217;s how they do it at the Mayo Clinic, from Steve May:</p>
<blockquote><p>We have our own low voltage and high voltage contractors for all in-house cable pulling, to include data pulls and all project related work, so <em>cable pulling and wiring costs are never part of an installation package, but an infrastructure cost which we earmark as Capital expenditures and plan/budget annually.</em> Bids &amp; labor costs are renewed by Purchasing every 2 years and our preferred contractors are all able to bid on both project services &amp; time &amp; material services. <a href="http://medicalconnectivity.com/2009/09/22/medical-device-system-networking-issues/#more-1268" class="more-link">(more&#8230;)</a></p>
]]></content:encoded>
			<wfw:commentRss>http://medicalconnectivity.com/2009/09/22/medical-device-system-networking-issues/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Market Trends Series: Wireless Connectivity</title>
		<link>http://medicalconnectivity.com/2009/09/17/market-trends-series-wireless-connectivity/</link>
		<comments>http://medicalconnectivity.com/2009/09/17/market-trends-series-wireless-connectivity/#comments</comments>
		<pubDate>Thu, 17 Sep 2009 22:34:45 +0000</pubDate>
		<dc:creator>Brian McAlpine</dc:creator>
		
		<category><![CDATA[Uncategorized]]></category>

		<category><![CDATA[Wireless Medical Devices]]></category>

		<guid isPermaLink="false">http://medicalconnectivity.com/2009/09/17/market-trends-series-wireless-connectivity/</guid>
		<description><![CDATA[There are quite a few device manufacturers that offer wireless in their devices. However, there are really only a few vendors that have done wireless right.]]></description>
			<content:encoded><![CDATA[<p><!--[if gte mso 9]&amp;gt;           &amp;lt;![endif]--></p>
<p><!--[if gte mso 9]&amp;gt;     Normal   0               false   false   false      EN-US   X-NONE   X-NONE                                                                                                     &amp;lt;![endif]--><!--[if gte mso 9]&amp;gt;                                                                                                                                                                                                                                                                                                                                                                                                                                &amp;lt;![endif]--> <!--  /* Font Definitions */  @font-face 	{font-family:"Cambria Math"; 	panose-1:2 4 5 3 5 4 6 3 2 4; 	mso-font-charset:1; 	mso-generic-font-family:roman; 	mso-font-format:other; 	mso-font-pitch:variable; 	mso-font-signature:0 0 0 0 0 0;} @font-face 	{font-family:Calibri; 	panose-1:2 15 5 2 2 2 4 3 2 4; 	mso-font-charset:0; 	mso-generic-font-family:swiss; 	mso-font-pitch:variable; 	mso-font-signature:-1610611985 1073750139 0 0 159 0;}  /* Style Definitions */  p.MsoNormal, li.MsoNormal, div.MsoNormal 	{mso-style-unhide:no; 	mso-style-qformat:yes; 	mso-style-parent:""; 	margin:0in; 	margin-bottom:.0001pt; 	mso-pagination:widow-orphan; 	font-size:11.0pt; 	font-family:"Calibri","sans-serif"; 	mso-fareast-font-family:Calibri; 	mso-fareast-theme-font:minor-latin; 	mso-bidi-font-family:"Times New Roman";} .MsoChpDefault 	{mso-style-type:export-only; 	mso-default-props:yes; 	mso-ascii-font-family:Calibri; 	mso-ascii-theme-font:minor-latin; 	mso-fareast-font-family:Calibri; 	mso-fareast-theme-font:minor-latin; 	mso-hansi-font-family:Calibri; 	mso-hansi-theme-font:minor-latin; 	mso-bidi-font-family:"Times New Roman"; 	mso-bidi-theme-font:minor-bidi;} .MsoPapDefault 	{mso-style-type:export-only; 	margin-bottom:10.0pt; 	line-height:115%;} @page Section1 	{size:8.5in 11.0in; 	margin:1.0in 1.0in 1.0in 1.0in; 	mso-header-margin:.5in; 	mso-footer-margin:.5in; 	mso-paper-source:0;} div.Section1 	{page:Section1;} --> <!--[if gte mso 10]&amp;gt;   /* Style Definitions */  table.MsoNormalTable 	{mso-style-name:"Table Normal"; 	mso-tstyle-rowband-size:0; 	mso-tstyle-colband-size:0; 	mso-style-noshow:yes; 	mso-style-priority:99; 	mso-style-qformat:yes; 	mso-style-parent:""; 	mso-padding-alt:0in 5.4pt 0in 5.4pt; 	mso-para-margin-top:0in; 	mso-para-margin-right:0in; 	mso-para-margin-bottom:10.0pt; 	mso-para-margin-left:0in; 	line-height:115%; 	mso-pagination:widow-orphan; 	font-size:11.0pt; 	font-family:"Calibri","sans-serif"; 	mso-ascii-font-family:Calibri; 	mso-ascii-theme-font:minor-latin; 	mso-fareast-font-family:"Times New Roman"; 	mso-fareast-theme-font:minor-fareast; 	mso-hansi-font-family:Calibri; 	mso-hansi-theme-font:minor-latin;}  &amp;lt;![endif]-->Fresh back from the <a href="http://medicalconnectivity.com/2009/09/17/medical-device-connectivity-conference-wrap-up/">MDC Conference</a> in Boston last week - great inaugural event and a perfect venue at Harvard Medical School. Thanks to Tim and the conference organizers &#8212; I personally heard many very positive comments from a number of attendees.</p>
<p>As the healthcare market continues to evolve, so do solutions related to medical device connectivity. I would like to invite you to join me in a dialog over the next several weeks - perhaps even on an ongoing basis - that will explore the trends that are affecting the market of medical device connectivity.  The idea is to have an open and interactive discussion on where the technology is today, where it needs to go, and what is driving the market.  Remember that this is just my viewpoint as I see things based on my experiences. Perhaps your experiences and perspective are similar or maybe they are completely different.</p>
<p>So, let’s begin.  The first trend I’d like to talk about is wireless medical devices and the impact on connectivity.  We all know that more and more medical devices are becoming wireless and therefore more mobile, for example more and more smart IV pumps (smart pumps) are being implemented every day. One key aspect of wireless technology is the fact that wireless enables devices to become untethered, and therefore a mobile use case is enabled. Wireless medical devices such as smart IV pumps and patient monitors add to the list of connectivity challenges because, from a pure connectivity perspective, they have basically eliminated one problem (the use of a serial data cable) and often create others. Once a medical device is no longer connected to something that facilitates data integration (like a bedside terminal server for example), then part of the connectivity and integration problem often shifts onto the manufacturer of the medical device.<br />
 <a href="http://medicalconnectivity.com/2009/09/17/market-trends-series-wireless-connectivity/#more-1265" class="more-link">(more&#8230;)</a></p>
]]></content:encoded>
			<wfw:commentRss>http://medicalconnectivity.com/2009/09/17/market-trends-series-wireless-connectivity/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Convergence Summit - Day One</title>
		<link>http://medicalconnectivity.com/2009/05/13/convergence-summit-day-one/</link>
		<comments>http://medicalconnectivity.com/2009/05/13/convergence-summit-day-one/#comments</comments>
		<pubDate>Thu, 14 May 2009 05:30:36 +0000</pubDate>
		<dc:creator>Tim Gee</dc:creator>
		
		<category><![CDATA[Events]]></category>

		<category><![CDATA[Remote Monitoring]]></category>

		<category><![CDATA[Wireless Medical Devices]]></category>

		<guid isPermaLink="false">http://medicalconnectivity.com/2009/05/13/convergence-summit-day-one/</guid>
		<description><![CDATA[Many companies are too focused on finishing a product, and missing things in regulatory and the "whole product solution" that will drive adoption.]]></description>
			<content:encoded><![CDATA[<p>I&#8217;m at the <a href="http://www.wirelesslifesciences.org/">Wireless-Life Sciences Alliance</a> conference, called the Convergence Summit, May 13 and 14. Held at the Estancia La Jolla hotel, today was a full house &#8212; standing room only.  A few of us are also Twittering the event; you can search for #wlsa to pull up everyone&#8217;s posts. You can also see the Summit agenda and prestentors <a href="http://wirelesslifesciences.org/event/2009Summit/schedule.php">here</a>.</p>
<p>During breakfast, I chatted with Michael Kurgan, CEO of start-up Service Wing Healthcare. They&#8217;re targeting the wireless gateway market to support body area networks. I mentioned a company I heard about yesterday, <a href="http://www.gainspan.com/">GainSpan</a> and Michael had some great perspective on the challenges picking tech winners in immature markets. GainSpan has an ultra low power wireless SOC (system-on-chip) that includes an 802.11b radio and two ARM processors, one for the radio and one to drive whatever device the chip is enabling. In an immature market, just because a component comes from a big company does not mean that their component will have long term success. A much smaller competitor with a better solution may win, or the big company may acquire a better solution in order to be a big player in that market segment.</p>
<p>Rob McCray, chair of the Wireless-Life Sciences Alliance, kicked things off. Camille Sobrian was up next, touting San Diego as the biggest wireless hot spot in the world (perhaps for <em>cellular</em> wireless). She also mentioned the <a href="http://www.westwirelesshealth.org/">West Wireless Health Institute</a>, and the upcoming <a href="http://www.tedmed.com/">TEDMED</a> event. Dr. Paul Jacobs, CEO and chair of Qualcomm passed on introductory remarks and jumped right into things wireless.</p>
<p>Paul noted that what&#8217;s going on right now is convergence, and it&#8217;s those who understand both industries that can lead that convergence. He described the new mobile internet experience: networks, devices and applications in the cloud. Multiple air interfaces are a key enabling component. The newest radios are only a few percent more efficient, but they tend to support broader bandwidth to improve network performance. He mentioned a mobile WAN, and various wireless LANs and BANs. A future trend is where applications control the radio to optimize performance for that application.</p>
<p>In Europe, mobile broadband radio dongles for connecting laptops outsell all the 3G phones sold there. Paul defined convergence as the overlapping of computing devices, consumer electronics and wireless tech. Paul alluded to the Amazon Kindle, as a prototypical device for the future, where an embedded system includes a cell phone built in for connectivity. He also highlighted <a href="http://www.qualcomm.com/news/releases/2007/071114_Qualcomm_Snapdragon.html">Snapdragon </a>as a platform for mobile data processing, multimedia performance, 3G<a href="http://www.qualcomm.com/products_services/glossary/index.html#3g" onmouseout="doHideTerm()" onmouseover="showTerm('3G','3g','Third Generation wireless technology. Based on digital technology, 3G wireless networks offer increased voice capacity and provide higher data rates than 2G and 2.5G networks. As defined by the International Telecommunications Union (ITU), 3G technology has been or will be implemented as CDMA2000, CDMA2000 1xEV-DO, WCDMA/UMTS and HSDPA/HSUPA.')" id="activator3g" style="text-decoration: none"><span class="glossary-item"></span></a> wireless connectivity and the low power consumption.</p>
<p> <a href="http://medicalconnectivity.com/2009/05/13/convergence-summit-day-one/#more-1246" class="more-link">(more&#8230;)</a></p>
]]></content:encoded>
			<wfw:commentRss>http://medicalconnectivity.com/2009/05/13/convergence-summit-day-one/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Can We Fix Wireless in Health Care?</title>
		<link>http://medicalconnectivity.com/2009/03/24/can-we-fix-wireless-in-health-care/</link>
		<comments>http://medicalconnectivity.com/2009/03/24/can-we-fix-wireless-in-health-care/#comments</comments>
		<pubDate>Tue, 24 Mar 2009 20:08:57 +0000</pubDate>
		<dc:creator>Tim Gee</dc:creator>
		
		<category><![CDATA[Wireless Medical Devices]]></category>

		<category><![CDATA[Bluetooth]]></category>

		<category><![CDATA[coexistence]]></category>

		<category><![CDATA[GE]]></category>

		<category><![CDATA[interference]]></category>

		<category><![CDATA[MBAN]]></category>

		<category><![CDATA[Philips]]></category>

		<category><![CDATA[WMTS]]></category>

		<category><![CDATA[ZigBee]]></category>

		<guid isPermaLink="false">http://medicalconnectivity.com/2009/03/24/can-we-fix-wireless-in-health-care/</guid>
		<description><![CDATA[Given the increasingly well known issues with Wi-Fi networks, I frequently get questions about alternatives.]]></description>
			<content:encoded><![CDATA[<p>Awareness is growing about the challenges of developing and maintaining safe and effective wireless medical devices. What with <a href="http://medicalconnectivity.com/2008/05/26/iec-80001-an-introduction/">IEC80001</a> moving forward (due to be finalized next year) and the recent series of <a href="http://medicalconnectivity.com/2009/01/06/workshop-on-wireless-tech-in-healthcare/">wireless medical device workshops</a>, people in hospitals and among vendors are asking more of the hard questions about wireless. Amongst the turmoil, participants are jostling for position. This post looks at common problems with Wi-Fi, a report from U.K. alliance ERBI, and some alternatives to Wi-Fi.</p>
<h3>Problems with Wireless</h3>
<p>Those of us who are old enough, think back to the golden age of wireless medical devices &#8212; channelized analog telemetry. These systems were so basic and limited in scope (a couple dozen transmitters typically covering just a single 30 bed unit) that they had few problems and required little maintenance.  Today, larger hospitals are pushing the envelope with a few hundred patient monitors and a thousand or more wireless infusion pumps. These wireless devices are using sophisticated client radio/access point (AP) communications protocols to maximize capacity, whether using Wi-Fi or WMTS. We&#8217;ve since left the golden age far in the past.</p>
<p>Radio frequency (RF) spectrum is a shared resource. There&#8217;s no getting around that fact, even with &#8220;dedicated&#8221; spectrum. The ether in which wireless signals move is like gases in the atmosphere or chemicals in water. There are no ways to practically segregate RF signals to specific areas, except for a <a href="http://en.wikipedia.org/wiki/Faraday_cage">Faraday cage</a>. In a health care facility, some shielded rooms in Radiology qualify as Faraday cages, but little else. Much of the rest of a health care facility consists of objects and structures that seem to perversely confound and obstruct RF communications in  ways like partially blocking and attenuating signals, creating <a href="http://en.wikipedia.org/wiki/Multipath_propagation">multipath interference</a>, and radiating both intentional and unintentional interference. <em>Intentional interference</em> is where two or more users of a portion of wireless spectrum get in each others way, disrupting or degrading the communications of one or both parties. When there are problems with two or more wireless devices using the same spectrum, this is intentional interference, often referred to as coexistence problems. <em>Unintentional interference</em> comes from electromechanical devices that accidentally spew RF signals as a consequence of some degradation or failure. Common sources of unintentional interference are florescent light balasts, blow dryers, paper shredders, elevator motors, or faulty microwaves. You can see a bunch of examples of RF interference on a spectrum analyzer (which everyone doing wireless medical devices should have, and know how to use) <a href="http://www.metageek.net/docs/signatures">here</a>.</p>
<p> <a href="http://medicalconnectivity.com/2009/03/24/can-we-fix-wireless-in-health-care/#more-1235" class="more-link">(more&#8230;)</a></p>
]]></content:encoded>
			<wfw:commentRss>http://medicalconnectivity.com/2009/03/24/can-we-fix-wireless-in-health-care/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Apple Targets Health Care with iPhone 3.0 OS</title>
		<link>http://medicalconnectivity.com/2009/03/19/apple-targets-health-care-with-iphone-30-os/</link>
		<comments>http://medicalconnectivity.com/2009/03/19/apple-targets-health-care-with-iphone-30-os/#comments</comments>
		<pubDate>Thu, 19 Mar 2009 21:17:30 +0000</pubDate>
		<dc:creator>Tim Gee</dc:creator>
		
		<category><![CDATA[Wireless Medical Devices]]></category>

		<guid isPermaLink="false">http://medicalconnectivity.com/2009/03/19/apple-targets-health-care-with-iphone-30-os/</guid>
		<description><![CDATA[There are 3 ways to leverage the iPhone at the point of care, each targeting different needs, productization strategies, and markets.]]></description>
			<content:encoded><![CDATA[<p>On March 17, Apple announced iPhone OS (operating system) 3.0 software and a new iPhone software development kit (SDK) for developers. The 3.0 software expected to be released this summer. The SDK is in beta form and can be downloaded now. (You can watch the event <a href="http://events.apple.com.edgesuite.net/0903lajkszg/event/index.html">here</a>. I got better performance after doing a save-as of the video and playing it in QuickTime rather than the browser.) For a general overview of the announcement, I recommend Gizmodo&#8217;s coverage, <a href="http://i.gizmodo.com/5171796/iphone-30-os-guide-everything-you-need-to-know">here</a> and <a href="http://i.gizmodo.com/5174053/iphone-30-beta-os-walkthrough-video">here</a>. Gizmodo also has a nice overview of the top 5 smart phone platforms (iPhone, Android, Windows Mobile, Blackberry, Palm Pre) <a href="http://i.gizmodo.com/5173865/giz-explains-what-makes-the-five-smartphone-platforms-different">here</a>. Also note that the iPod Touch offers most all the functionality of the iPhone, except for mobile phone features. The iPod Touch would make an attractive alternative to the iPhone (smaller, less expensive) in many health care applications.</p>
<p>The announcement started with some bragging. Apple has sold more than 30 million iPhones and iPod Touches since they were introduced in 2007 to the end of 2008. The market for third party applications, distributed through Apple&#8217;s App Store has likewise been phenomenally successful. With this new announcement, Apple signaled their intent to strengthen their hold on games and other consumer apps, and extend into vertical markets like the enterprise and health care.</p>
<p>There are many new features in the 3.0 iPhone software, but the announcement was really more about Apple&#8217;s new SDK  for the iPhone. The SDK is what third party developers use to design accessories and software for the iPhone. This new SDK exposes for the first time, about a thousand software features (what Apple calls APIs, for application programing interfaces) that can now be used by third party developers.</p>
<h3>Key Features for Health Care</h3>
<p> <a href="http://medicalconnectivity.com/2009/03/19/apple-targets-health-care-with-iphone-30-os/#more-1236" class="more-link">(more&#8230;)</a></p>
]]></content:encoded>
			<wfw:commentRss>http://medicalconnectivity.com/2009/03/19/apple-targets-health-care-with-iphone-30-os/feed/</wfw:commentRss>
		</item>
		<item>
		<title>.NET Micro Framework: Good Choice for Medical Devices?</title>
		<link>http://medicalconnectivity.com/2009/01/12/net-micro-framework-good-choice-for-medical-devices/</link>
		<comments>http://medicalconnectivity.com/2009/01/12/net-micro-framework-good-choice-for-medical-devices/#comments</comments>
		<pubDate>Mon, 12 Jan 2009 20:12:06 +0000</pubDate>
		<dc:creator>Chris Bolinger</dc:creator>
		
		<category><![CDATA[Wireless Medical Devices]]></category>

		<guid isPermaLink="false">http://medicalconnectivity.com/2009/01/12/net-micro-framework-good-choice-for-medical-devices/</guid>
		<description><![CDATA[The largest cost area, in adding wireless connectivity, often is overlooked.]]></description>
			<content:encoded><![CDATA[<p>The cost of adding Wi-Fi connectivity to a medical device is more than the cost of the Wi-Fi radio itself. To support the radio, the device may require more memory and processing power than a base device with no Wi-Fi support. In addition, the device will need connectivity software, such as a TCP/IP software stack.</p>
<p>The largest cost area, however, often is overlooked. It is the cost of making the Wi-Fi radio run well on the device, where running well means providing secure, reliable connectivity even when the device is in motion in an environment that provides challenges to Wi-Fi connectivity, i.e., your typical hospital. The burden of ensuring that a Wi-Fi radio supports all required features and runs well on the device falls squarely on the shoulders of a software program called the Wi-Fi device driver.</p>
<p>Device drivers for a broad range of Wi-Fi radios are readily available on Microsoft operating systems and Linux. For the embedded operating systems that run on most medical devices, however, Wi-Fi device drivers are scarce. Rather than writing their own &#8212; <a href="http://medicalconnectivity.com/2008/05/13/driving-miss-wi-fi/">an expensive and time-consuming process</a> &#8212; some medical device makers are selecting Windows Embedded CE instead of an embedded OS. For resource-constrained medical devices, however, CE is too “big”.  For others, it’s simply too complex and inefficient.</p>
<p>A more attractive alternative from Microsoft may be the .NET Micro Framework, which Microsoft calls “an innovative development and execution environment for resource-constrained devices”. The .NET Micro Framework is a bootable runtime module that requires only 300 KB of memory but provides a full managed execution environment. The module can run on top of an underlying operating system or can run natively on a device. <a href="http://medicalconnectivity.com/2009/01/12/net-micro-framework-good-choice-for-medical-devices/#more-1229" class="more-link">(more&#8230;)</a></p>
]]></content:encoded>
			<wfw:commentRss>http://medicalconnectivity.com/2009/01/12/net-micro-framework-good-choice-for-medical-devices/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Workshop on Wireless Tech in Healthcare</title>
		<link>http://medicalconnectivity.com/2009/01/06/workshop-on-wireless-tech-in-healthcare/</link>
		<comments>http://medicalconnectivity.com/2009/01/06/workshop-on-wireless-tech-in-healthcare/#comments</comments>
		<pubDate>Wed, 07 Jan 2009 01:11:13 +0000</pubDate>
		<dc:creator>Tim Gee</dc:creator>
		
		<category><![CDATA[Wireless Medical Devices]]></category>

		<guid isPermaLink="false">http://medicalconnectivity.com/2009/01/06/workshop-on-wireless-tech-in-healthcare/</guid>
		<description><![CDATA[We need to solve this problem for today and into the future, rather than tailor the solution to a specific technology like 802.11.]]></description>
			<content:encoded><![CDATA[<p>On December 19, 2008, a group of about 50 people met to to discuss wireless medical devices. The event was organized by <a href="http://lib.bioinfo.pl/auth:Witters,D">Don Witters</a> of the FDA, <a href="http://www70.homepage.villanova.edu/elliot.sloane/">Elliot Sloane</a> from Villanova (and contributor to HITSP, IHE, ACCE and others), the wireless Czar of Partners Healthcare, <a href="http://www.umsec.umn.edu/events/sss_08/Rick-Hampton">Rick Hampton</a>, and ubiquitous industry standards maven, <a href="http://www.linkedin.com/pub/6/369/304">Todd Cooper</a>. The meeting was held in the new nursing school building at Villanova with a live video teleconference connection to <a href="http://www.sei.cmu.edu/">Carnegie Mellon University</a> (CMU) in Pittsburgh.</p>
<p>The meeting was billed as a workshop on wireless technology in health care, with an emphasis on what is needed for safe, secure and reliable deployment. (You can download the agenda that was sent out <a href="http://medicalconnectivity.com/wp-content/uploads/2009/VillanovaWirelessMedicalDeviceWorkshop-VillanovaIEEESEI-19Dec2008-1216.doc">here</a>.) A wide net was cast, and participants represented Wi-Fi infrastructure vendors (Cisco, Trapeze, Aruba, Motorola, InnerWireless, MobileAccess), medical device vendors (Hospira, Philips Research, GE Healthcare, Sigma International, Smiths Medical, Welch Allyn, Draeger), AAMI, ASHE, the Medical Records Institute, Bosch, Verizon, ECRI Institute, NIST, various academics (Drexler and U of OK besides Villanova and CMU). The only provider organizations attending, besides Partners, were Memorial Sloan-Kettering, Kaiser and the VA. GlobeStar Systems was the lone health care software vendor. Due to limited seating, not everyone who wanted to attend was able to be accommodated.</p>
<p>Elliot kicked things off with a welcome and review of the agenda. Don Witters then came up and set the stage from the safety perspective, and Rick Hampton did the same relative to Partners&#8217; position as a provider organization. We wrapped the first portion of the agenda by going around the room in both locations introducing ourselves. The rest of the day focused on two sets of break out discussions:</p>
<ul>
<li>Group A - identifying stakeholders, benefits, challenges, risks</li>
<li>Group B - Identifying/categorizing critical wireless medical device/network security dimensions/factors for CIA&amp;S (confidentiality, integrity, availability and safety)</li>
<li>Group C - CIA&amp;S, performance metrics that could/should be cataloged (e.g., QoS, bandwidth, etc.)</li>
<li>Group D - System design and life cycle maintenance, verification and validation strategies, and sources to assure CIA&amp;S in future applications</li>
</ul>
<p>Throughout the day discussions sought to identify wireless problems and get to root causes. <a href="http://medicalconnectivity.com/2009/01/06/workshop-on-wireless-tech-in-healthcare/#more-1228" class="more-link">(more&#8230;)</a></p>
]]></content:encoded>
			<wfw:commentRss>http://medicalconnectivity.com/2009/01/06/workshop-on-wireless-tech-in-healthcare/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Medical Device Networks Trouble Industry</title>
		<link>http://medicalconnectivity.com/2008/12/18/medical-device-networks-trouble-industry/</link>
		<comments>http://medicalconnectivity.com/2008/12/18/medical-device-networks-trouble-industry/#comments</comments>
		<pubDate>Fri, 19 Dec 2008 01:33:31 +0000</pubDate>
		<dc:creator>Tim Gee</dc:creator>
		
		<category><![CDATA[Healthcare IT]]></category>

		<category><![CDATA[Wireless Medical Devices]]></category>

		<guid isPermaLink="false">http://medicalconnectivity.com/2008/12/18/medical-device-networks-trouble-industry/</guid>
		<description><![CDATA[Make no mistake, enterprise networking issues have killed patients by impacting the operation of medical device systems.]]></description>
			<content:encoded><![CDATA[<p>Over the past few years, medical device networking has become increasingly problematic. There is a growing perception of declining service levels and network reliability. (I&#8217;ve not seen or heard about any quantitative data to back this up - let me know if you&#8217;ve got any - but these are substantive issues.) As medical devices, by way of connectivity and workflow automation, have been pulled into the sphere of the IT department risks to patient safety have increased.</p>
<p>These growing problems are a key factor in the creation of <a href="http://medicalconnectivity.com/2008/05/26/iec-80001-an-introduction/">IEC 8001</a> - which will have a <a href="http://medicalconnectivity.com/2008/06/16/iec-80001-to-impact-providers/">major impact</a> on how hospital&#8217;s deploy and manage networked medical devices. The current situation provides a lot of the impetus behind a meeting this week at Villanova on wireless technology in health care. So what&#8217;s the big deal?</p>
<h3>Private Medical Device Networks</h3>
<p>In the good old days, all medical device systems operated on private networks that were designed, installed and supported by the medical device vendor. Vendors decided exactly how the would handle IP addressing (static or DHCP) and every other configuration option. This minimized vendor&#8217;s product development costs, shortened time to market, and made service and support easy (because the network was <em>their</em> sandbox). When they got the inevitable calls from customers that, &#8220;your system just brought down our network,&#8221; vendors could quickly and easily determine if that was the case - and just as importantly, quickly prove to hospital network administrators why their answer was correct.</p>
<p>Providers benefited from this approach in a number of ways. First, vendor system support was quick, efficient and reasonably priced. This approach also relieved hospitals of the need to assume responsibility for supporting life critical applications themselves.</p>
<p>Of course nothing&#8217;s perfect, and relying on private networks created a few problems of its own. As more medical devices evolved to become components in medical device <em>systems</em> connected by networks, these private networks proliferated. The IT department of a thousand bed hospital system on the east coast did a survey a couple years ago of their networked medical device systems, and &#8220;discovered&#8221; over 200 private networks. And unlike enterprise networks that must be kept up to date to ensure cross vendor interoperability and coexistence, private medical device networks are like time capsules. With the exception of occasional failures of a switch or router, medical device networks remain unchanged from the day they&#8217;re installed; the hospital mentioned earlier found numerous ThickNet and ThinNet Ethernet networks in their survey of medical device systems.</p>
<p>Over time, medical device vendors have given some ground by moving from physically separate private networks, to creating logically separate private networks through the use of network switches and routers. <a href="http://medicalconnectivity.com/2008/12/18/medical-device-networks-trouble-industry/#more-1226" class="more-link">(more&#8230;)</a></p>
]]></content:encoded>
			<wfw:commentRss>http://medicalconnectivity.com/2008/12/18/medical-device-networks-trouble-industry/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Why Wireless Connectivity is Different</title>
		<link>http://medicalconnectivity.com/2008/11/06/why-wireless-connectivity-is-different/</link>
		<comments>http://medicalconnectivity.com/2008/11/06/why-wireless-connectivity-is-different/#comments</comments>
		<pubDate>Thu, 06 Nov 2008 17:46:18 +0000</pubDate>
		<dc:creator>Brian McAlpine</dc:creator>
		
		<category><![CDATA[Wireless Medical Devices]]></category>

		<category><![CDATA[connectivity]]></category>

		<category><![CDATA[barcode]]></category>

		<category><![CDATA[patient context]]></category>

		<category><![CDATA[wireless]]></category>

		<guid isPermaLink="false">http://medicalconnectivity.com/2008/11/06/why-wireless-connectivity-is-different/</guid>
		<description><![CDATA[In fact, more connectivity problems are created than solved by many wireless medical devices.]]></description>
			<content:encoded><![CDATA[<p>Wireless changes everything …</p>
<p>I have been watching the evolution of wireless bedside medical device connectivity for several years now. It is now fairly common for medical devices to communicate wirelessly and most hospitals now have the requisite Wi-Fi networks installed and operational. In fact, the saturation point of WLAN adoption in US hospitals has been reached as <a href="http://www.abiresearch.com/products/RB/WIFI/105/file/1432">the numbers</a> are quickly approaching 90% of all US hospitals.</p>
<p>But this posting is not about Wi-Fi or other wireless technologies used in medical devices. Rather it is about additional connectivity considerations beyond the actual wireless connection of the device to a network. Regardless of the wireless connection technology or standard used, wireless changes everything when it comes to connectivity.</p>
<p> <a href="http://medicalconnectivity.com/2008/11/06/why-wireless-connectivity-is-different/#more-1220" class="more-link">(more&#8230;)</a></p>
]]></content:encoded>
			<wfw:commentRss>http://medicalconnectivity.com/2008/11/06/why-wireless-connectivity-is-different/feed/</wfw:commentRss>
		</item>
	</channel>
</rss>
