<?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; Uncategorized</title>
	<link>http://medicalconnectivity.com</link>
	<description></description>
	<pubDate>Thu, 15 May 2008 21:33:47 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3.3</generator>
	<language>en</language>
			<item>
		<title>Connectivity - The Book</title>
		<link>http://medicalconnectivity.com/2008/03/03/connectivity-the-book/</link>
		<comments>http://medicalconnectivity.com/2008/03/03/connectivity-the-book/#comments</comments>
		<pubDate>Tue, 04 Mar 2008 04:07:52 +0000</pubDate>
		<dc:creator>Tim Gee</dc:creator>
		
		<category><![CDATA[Uncategorized]]></category>

		<guid isPermaLink="false">http://medicalconnectivity.com/2008/03/03/connectivity-the-book/</guid>
		<description><![CDATA[I can think of several terrific contributors.]]></description>
			<content:encoded><![CDATA[<p><img src="http://medicalconnectivity.com/wp-content/uploads/2008/Writer.jpg" alt="LibraryLindy as rich guy" height="186" width="200" />Last October I was asked if I&#8217;d ever written a book. The answer was, and remains, that I have not. But then I&#8217;m not aware of any else having written a book on medical connectivity. After some thought, it seems that the market may be ready for such a literary epic. (I&#8217;m going to have to start wearing turtlenecks or ascots and smoking a pipe.)</p>
<p>The past few weeks I&#8217;ve been talking to people asking about publishers and such. I&#8217;ve got a few leads, but if you can suggest anyone to contact please let me know.</p>
<p>Here&#8217;s what I&#8217;ve been able to noodle out: <a href="http://medicalconnectivity.com/2008/03/03/connectivity-the-book/#more-1157" class="more-link">(more&#8230;)</a></p>
]]></content:encoded>
			<wfw:commentRss>http://medicalconnectivity.com/2008/03/03/connectivity-the-book/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Tuesday Morning at HIMSS</title>
		<link>http://medicalconnectivity.com/2008/02/26/tuesday-morning-at-himss/</link>
		<comments>http://medicalconnectivity.com/2008/02/26/tuesday-morning-at-himss/#comments</comments>
		<pubDate>Tue, 26 Feb 2008 13:05:12 +0000</pubDate>
		<dc:creator>Tim Gee</dc:creator>
		
		<category><![CDATA[Uncategorized]]></category>

		<guid isPermaLink="false">http://medicalconnectivity.com/2008/02/26/tuesday-morning-at-himss/</guid>
		<description><![CDATA["How would your marketing guy describe this?" His reply, "I am the marketing guy." ]]></description>
			<content:encoded><![CDATA[<p><img src="http://medicalconnectivity.com/wp-content/uploads/2008/Intellidot.jpg" alt="Intellidot" height="269" width="350" /></p>
<p>A bleary eyed day 3 of HIMSS. There&#8217;s a lot of energy at the show this year - the exhibit hall is full with both attendees and exhibitors. Many write about the theme or hot topics at events. HIMSS has gotten so big, with such depth, that its easy to find that your interests are the hot topic at HIMSS. There have been some interesting announcements, which I&#8217;ll post on in the coming days. Many vendors have refined or shifted their strategies in ways that will impact their future products and customers.Yesterday I caught up with a very old friend. We started attending HIMSS over 20 years ago. He observed that some things never change.</p>
<p>There&#8217;s still a tremendous amount of spin and vapor ware. Sure there are new vendors and fresh faces but an alarming number of vendors still can&#8217;t describe their product in understandable language or articulate their value proposition beyond an alphabet soup of acronyms, &#8220;glamor words&#8221; and jargon. In meeting with one vendor yesterday, I asked repeatedly, &#8220;what is this?&#8221; In frustration I asked, &#8220;how would your marketing guy describe this?&#8221; His reply, &#8220;I am the marketing guy.&#8221; Uh, open mouth, insert foot&#8230;</p>
<p>Pictured at top is the only mobile device at HIMSS (or anywhere else) purpose built for health care from <a href="http://www.intellidot.net/">Intellidot</a>.</p>
]]></content:encoded>
			<wfw:commentRss>http://medicalconnectivity.com/2008/02/26/tuesday-morning-at-himss/feed/</wfw:commentRss>
		</item>
		<item>
		<title>HIMSS Pre-show</title>
		<link>http://medicalconnectivity.com/2008/02/22/himss-pre-show/</link>
		<comments>http://medicalconnectivity.com/2008/02/22/himss-pre-show/#comments</comments>
		<pubDate>Fri, 22 Feb 2008 18:48:46 +0000</pubDate>
		<dc:creator>Tim Gee</dc:creator>
		
		<category><![CDATA[Uncategorized]]></category>

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

		<guid isPermaLink="false">http://medicalconnectivity.com/2008/02/22/himss-pre-show/</guid>
		<description><![CDATA[Come to Meet the Bloggers]]></description>
			<content:encoded><![CDATA[<p><img src="http://medicalconnectivity.com/wp-content/uploads/2008//himssladies.jpg" alt="HIMSS Greeters" /><br class="webkit-block-placeholder" />I&#8217;m on my way to HIMSS today, and really looking forward to this year&#8217;s conference and exhibits.There&#8217;s lots of interesting rumblings among the market segments that I follow.</p>
<p>There will be big news among RTLS/RFID vendors and I&#8217;m expecting some announcements from a number of connectivity companies.</p>
<p>As in years past, I&#8217;m attending as a contributing editor for MX Magazine. As such I&#8217;ve been inundated by PR folks for appointments. For the first time, I&#8217;ve used an <a href="http://http://planner.zoho.com/public/publicpage.jsp?PageId=207183">online schedule</a> to coordinate things. HIMSS only comes once a year, and I always try to make the most of it.</p>
<p>Meet the Bloggers</p>
<p>I&#8217;m very late with a post this year, but there <span style="font-style: italic" class="Apple-style-span">will</span> be a meet the bloggers gathering during the HIMSS opening reception - that&#8217;s Sunday between 5 and 8 pm (here&#8217;s a <a href="http://www.himssconference.org/networking/openingRec.aspx">link</a>).  Look for the big blue and orange sign with &#8220;Meet the Bloggers&#8221; and come by and say hi.</p>
]]></content:encoded>
			<wfw:commentRss>http://medicalconnectivity.com/2008/02/22/himss-pre-show/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Greetings</title>
		<link>http://medicalconnectivity.com/2008/02/20/greetings/</link>
		<comments>http://medicalconnectivity.com/2008/02/20/greetings/#comments</comments>
		<pubDate>Wed, 20 Feb 2008 14:57:46 +0000</pubDate>
		<dc:creator>Tim Gee</dc:creator>
		
		<category><![CDATA[Uncategorized]]></category>

		<guid isPermaLink="false">http://medicalconnectivity.com/2008/02/20/greetings/</guid>
		<description><![CDATA[A whole new look and feel]]></description>
			<content:encoded><![CDATA[<p>What you see today is the new design for the site. I&#8217;ve been contemplating this for some time. The biggest issue was getting the 1,100+ previous posts created using the old software into this system. That should be done in the next few hours.</p>
<p>Enjoy!</p>
]]></content:encoded>
			<wfw:commentRss>http://medicalconnectivity.com/2008/02/20/greetings/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Medical Device Interoperability Lags Behind Technological Capacity</title>
		<link>http://medicalconnectivity.com/2007/12/19/medical-device-interoperability-lags-behind-technological-capacity/</link>
		<comments>http://medicalconnectivity.com/2007/12/19/medical-device-interoperability-lags-behind-technological-capacity/#comments</comments>
		<pubDate>Wed, 19 Dec 2007 18:42:17 +0000</pubDate>
		<dc:creator>Tim Gee</dc:creator>
		
		<category><![CDATA[Uncategorized]]></category>

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

		<category><![CDATA[EMR integration]]></category>

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

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

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

		<guid isPermaLink="false">http://medicalconnectivity.com/2007/12/19/medical-device-interoperability-lags-behind-technological-capacity/</guid>
		<description><![CDATA[Yours truly was quoted in an article in FDC Reports&#8217; newsletter The Gray Sheet (subscription only) last week about connectivity. The story was inspired by a comment from Bill Crounse, the director of Worldwide Health at Microsoft, during the World Healthcare
Innovation and Technology Congress held in Washington, D.C., earlier this month. He said, &#8220;&#8221;I no
longer [...]]]></description>
			<content:encoded><![CDATA[<p>Yours truly was quoted in an article in FDC Reports&#8217; newsletter <a href="http://www.thegraysheet.com/">The Gray Sheet</a> (subscription only) last week about connectivity. The story was inspired by a comment from Bill Crounse, the director of Worldwide Health at Microsoft, during the World Healthcare<br />
Innovation and Technology Congress held in Washington, D.C., earlier this month. He said, &#8220;&#8221;I no<br />
longer believe that technology is really the issue that prevents us from getting<br />
things done. We have the technology &#8230; We&#8217;ve cracked the code on things like<br />
mobility and wireless devices and broadband. The remaining barriers are really all-around barriers to adoption.&#8221;</p>
<p>The story provides an overview of connectivity in both acute care and remote monitoring, from both vendor and customer perspectives. The story closes with this observation:</p>
<p style="margin-left: 40px">&#8220;The<br />
medical device companies are becoming chimeras, where they&#8217;re part IT company,<br />
and they&#8217;re part embedded system company,&#8221; Gee noted. But, as long as their<br />
mindset remains that of an embedded system company trying to protect the &#8220;black<br />
box&#8221; of proprietary system design, it will be difficult to move forward, he<br />
said.</p>
<p>Jason Williams expresses a similar lament about the lack of connectivity in a great post on NeoTool&#8217;s blog titled, <a href="http://www.neotool.com/blog/2007/11/06/bridging-the-device-divide/">Bridging the Device Divide</a>. In a comment to the post, standards guru Todd Cooper observes:</p>
<p style="margin-left: 40px">Bottom line is that medical device vendors make more money with either<br />
proprietary connectivity or strategic partnerships, and end users -<br />
provider orgs - do not demand open standards-based connectivity. It is<br />
often called out in RFPs - but gets dropped in the decision making<br />
process. K-P [Kaiser Permanente] is one of the few org&#8217;s drawing a line in the sand on PnP<br />
med dev connectivity. &#8220;Collaborative partnerships&#8221; are the status quo<br />
and have been the basis of controlling and limiting device connectivity<br />
both at the PoC and to the enterprise.</p>
<p>Todd&#8217;s referring to Kaiser&#8217;s new purchase contract language that specifies medical device vendor responsibilities for supporting connectivity. You can read an except of the contract language in <a href="http://medicalconnectivity.com/2007/06/26.html">this post</a>. Rumor has it that Philips has recently declined to meet some of those requirements; it will be interesting see if Kaiser sticks to their guns and drops Philips as their patient monitoring vendor going forward.</p>
<p>In Jason&#8217;s blog post he quotes Robert Nadler who says, &#8220;&#8230;our business is building medical devices, not EMR solutions.&#8221; I don&#8217;t think medical device vendors will have the luxury of maintaining that point of view for much longer. I spoke with David Freeman and Munesh Makhija of GE Healthcare&#8217;s patient monitoring group a few weeks ago. They attended the <a href="http://en.cmef.com.cn/">CMEF</a> and saw an exhibit floor filled with vendors who are doing the same color displays with waveforms that GE is doing - at 30% lower cost. Rather than playing the manufacturing cost game, GE is looking to software to add clinical value and differentiate from low price competitors. Philips seems to be taking a similar approach with their acquisitions of <a href="http://medicalconnectivity.com/2007/12/07.html">Emergin</a> and <a href="http://histalk2.com/2007/12/18/philips-to-acquire-visicu-for-430-million/">VisICU</a>.</p>
<p>The days of staying in that nice familiar embedded device comfort zone are limited. This has always been the case as connectivity transforms medical device product categories. Remember E for M? They were once the market leader in cath lab recorders. They too decided they didn&#8217;t want to do software. They contrast nicely with Marquette Electronics who saw connectivity as an opportunity and redefined the product category - driving E for M out of business and capturing a major share of the cath lab market. (Another great example of leveraging connectivity is Alaris.)</p>
<p>You can access both Jason&#8217;s and Bob&#8217;s excellent blogs from the Blog Roll in the right hand column of this web page.</p>
]]></content:encoded>
			<wfw:commentRss>http://medicalconnectivity.com/2007/12/19/medical-device-interoperability-lags-behind-technological-capacity/feed/</wfw:commentRss>
		</item>
		<item>
		<title>42 Questions HHS Might Ask During a HIPAA Audit</title>
		<link>http://medicalconnectivity.com/2007/10/11/42-questions-hhs-might-ask-during-a-hipaa-audit/</link>
		<comments>http://medicalconnectivity.com/2007/10/11/42-questions-hhs-might-ask-during-a-hipaa-audit/#comments</comments>
		<pubDate>Fri, 12 Oct 2007 02:18:00 +0000</pubDate>
		<dc:creator>Tim Gee</dc:creator>
		
		<category><![CDATA[Uncategorized]]></category>

		<guid isPermaLink="false">http://medicalconnectivity.com/2007/10/11/42-questions-hhs-might-ask-during-a-hipaa-audit/</guid>
		<description><![CDATA[
Some recent projects have touched on HIPAA lately and I thought I&apos;d post on this Computerworld story about hapless Piedmont Hospital. They were the first hospital in to be audited by the Office of the Inspector General at the department of Health and Human Services for compliance with HIPAA security rules (emphasis mine).

The audit was [...]]]></description>
			<content:encoded><![CDATA[<p><img alt="Inspector-General-shield" src="http://medicalconnectivity.com/gems/Blog%20Photos/IG-Shield.gif" align="right" border="0" height="206" hspace="4" vspace="4" width="182"></p>
<p>Some recent projects have touched on HIPAA lately and I thought I&apos;d post on this <a href="http://www.computerworld.com/action/article.do?command=printArticleBasic&amp;articleId=9025253">Computerworld story</a> about hapless Piedmont Hospital. They were the first hospital in to be audited by the Office of the Inspector General at the department of Health and Human Services for compliance with HIPAA security rules (emphasis mine).
<div style="margin-left: 40px;">
<p>The audit was conducted by the office of the inspector general at<br />
the U.S. Department of Health and Human Service (HHS) <span style="font-weight: bold;">and is being seen<br />
by some in the health care industry as a precursor of similar audits to<br />
come at other institutions.</span></p>
<p>Neither Piedmont nor HHS officials have publicly confirmed the audit<br />
or spoken about it. That silence has sparked considerable curiosity<br />
about why Piedmont was targeted as well as the scope of the audit and<br />
the kind of information HHS was seeking.</p>
</div>
<p>How mysterious. Even more mysterious, Computerworld managed to get a copy of the 42 items that HHS officials wanted information on - within 10 days. Specifically, the feds wanted documentation on the policies and procedures for the following:
<div style="margin-left: 40px;">
<ol>
<li>Establishing and terminating users&apos; access to systems housing electronic patient health information (ePHI).</li>
<li>Emergency access to electronic information systems.</li>
<li>Inactive computer sessions (periods of inactivity).</li>
<li>Recording and examining activity in information systems that contain or use ePHI.</li>
<li>Risk assessments and analyses of relevant information systems that house or process ePHI data.</li>
<li>Employee violations (sanctions).</li>
<li>Electronically transmitting ePHI.</li>
<li>Preventing, detecting, containing and correcting security violations (incident reports).</li>
<li>Regularly reviewing records of information system activity, such as<br />
audit logs, access reports and security incident tracking reports.</li>
<li>Creating, documenting and reviewing exception reports or logs.<br />
Please provide a list of examples of security violation logging and<br />
monitoring.</li>
<li>Monitoring systems and the network, including a listing of all network perimeter devices, i.e. firewalls and routers.</li>
<li>Physical access to electronic information systems and the facility in which they are housed.</li>
<li>Establishing security access controls; (what types of security<br />
access controls are currently implemented or installed in hospitals&apos;<br />
databases that house ePHI data?).</li>
<li>Remote access activity i.e. network infrastructure, platform, access servers, authentication, and encryption software.</li>
<li>Internet usage.</li>
<li>Wireless security (transmission and usage).</li>
<li>Firewalls, routers and switches.</li>
<li>Maintenance and repairs of hardware, walls, doors, and locks in sensitive areas.</li>
<li>Terminating an electronic session and encrypting and decrypting ePHI.</li>
<li>Transmitting ePHI.</li>
<li>Password and server configurations.</li>
<li>Antivirus software.</li>
<li>Network remote access.</li>
<li>Computer patch management.</li>
</ol>
</div>
<p>You&apos;ve got that all documented, with training records, right? There was more.
<div style="margin-left: 40px;">
<ol>
<li>Please provide a list of all information systems that house ePHI<br />
data, as well as network diagrams, including all hardware and software<br />
that are used to collect, store, process or transmit ePHI.</li>
<li>Please provide a list of terminated employees.</li>
<li>Please provide a list of all new hires.</li>
<li>Please provide a list of encryption mechanisms use for ePHI.</li>
<li>Please provide a list of authentication methods used to identify users authorized to access ePHI.</li>
<li>Please provide a list of outsourced individuals and contractors<br />
with access to ePHI data, if applicable. Please include a copy of the<br />
contract for these individuals.</li>
<li>Please provide a list of transmission methods used to transmit ePHI over an electronic communications network.</li>
<li>Please provide organizational charts that include names and titles<br />
for the management information system and information system security<br />
departments.</li>
<li>Please provide entity wide security program plans (e.g System Security Plan).</li>
<li>Please provide a list of all users with access to ePHI data. Please identify each user&apos;s access rights and privileges.</li>
<li>Please provide a list of systems administrators, backup operators and users.</li>
<li>Please include a list of antivirus servers, installed, including their versions.</li>
<li>Please provide a list of software used to manage and control access to the Internet.</li>
<li>Please provide the antivirus software used for desktop and other devices, including their versions.</li>
<li>Please provide a list of users with remote access capabilities.</li>
<li>Please provide a list of database security requirements and settings.</li>
<li>Please provide a list of all Primary Domain Controllers (PDC) and<br />
servers (including Unix, Apple, Linux and Windows). Please identify<br />
whether these servers are used for processing, maintaining, updating,<br />
and sorting ePHI.</li>
<li>Please provide a list of authentication approaches used to verify a<br />
person has been authorized for specific access privileges to<br />
information and information systems.</li>
</ol>
</div>
<p>None of this is rocket science, and the regs allow you to secure your IT infrastructure however you like. Based on my experience, there are more than a few hospital IT departments that would fail an audit like this in spectacular fashion. As I&apos;ve noted before, biomed departments go through an audit like this as part of Joint Commission accreditation. </p>
<p>I would recommend that IT work with biomeds to make sure your medical devices can pass this same audit. These devices would include: 
<ul>
<li>PACS</li>
<li>Blood bank</li>
<li>Diagnostic medical device systems like cath labs, endoscopy, ECG, and any other diagnostic device connected to a networked computer for data acquisition, analysis, and reporting</li>
<li>Patient care device systems like &#8220;smart&#8221; infusion pumps, patient monitoring systems, networked ventilators - again any medical device connected to networked computers</li>
<li>Medical device systems that provide remote access to users (that includes most of the above)</li>
<li>Medical devices whose vendors provide remote service and support via the Internet or dial-up POTS</li>
</ul>
<p>Have fun! Pictured right is the badge you&apos;ll see when they visit.</p>
]]></content:encoded>
			<wfw:commentRss>http://medicalconnectivity.com/2007/10/11/42-questions-hhs-might-ask-during-a-hipaa-audit/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Patient Flow Recommendations and Predictions</title>
		<link>http://medicalconnectivity.com/2007/10/08/patient-flow-recommendations-and-predictions/</link>
		<comments>http://medicalconnectivity.com/2007/10/08/patient-flow-recommendations-and-predictions/#comments</comments>
		<pubDate>Tue, 09 Oct 2007 03:28:39 +0000</pubDate>
		<dc:creator>Tim Gee</dc:creator>
		
		<category><![CDATA[Uncategorized]]></category>

		<guid isPermaLink="false">http://medicalconnectivity.com/2007/10/08/patient-flow-recommendations-and-predictions/</guid>
		<description><![CDATA[
Research firm Arketi sent me a survey on hospital patient flow. Sponsored by patient flow software vendor StatCom, the survey sought to quantify the patient flow problem (how many ED boarders, hours on divert, room turn over times, etc.) and identify the departments contributing to, or ameliorating hospital patient throughput. This will all be good [...]]]></description>
			<content:encoded><![CDATA[<p><img alt="StatCom-hospital" src="http://medicalconnectivity.com/gems/Blog%20Photos/StatCom-hospital.jpg" align="right" border="1" height="246" hspace="4" vspace="4" width="200"></p>
<p>Research firm <a href="http://www.arketi.com/">Arketi</a> sent me a survey on hospital patient flow. Sponsored by patient flow software vendor <a href="http://www.statcom.com/">StatCom</a>, the survey sought to quantify the patient flow problem (how many ED boarders, hours on divert, room turn over times, etc.) and identify the departments contributing to, or ameliorating hospital patient throughput. This will all be good marketing data once the study is compiled.</p>
<p><span style="font-weight: bold;">Lack of Data</span><br />I was struck by a couple things missing from the study. From my experience, the biggest challenge facing hospitals seeking to improve patient throughput is the near total absence of performance data. Unless an effort is made to manually log performance data - with the oversight to ensure it is accurate and complete - hospitals have little data available to them. Such manual data gathering operations are expensive, time consuming and hard to sustain on a broad basis or for an extended period of time. </p>
<p>As the canary in the coal mine, the Emergency Department is the most common source for any detailed data, and often the squeaky wheel pushing for patient flow improvements. Consequently, data about hours on diversion, ED patient flow metrics, patient boarding, and reasons for boarding frequently represent the best patient flow data in hospitals. Once you get beyond the ED, available data drops off quickly.</p>
<p>Frequently, the best data available is aggregate ADT data that shows length of stay (LOS), transfers and discharges among individual departments and the hospital as a whole. Have you looked at your ADT data lately? Found all those duplicate transaction codes for decommissioned units (still in use)? Does everyone who enters ADT transactions or uses the data have the same understanding of what all those codes and locations really mean and when to use them? If you;ve not addressed this issue (cleaning up your tables, training users, auditing data) in the past year or two, or don&apos;t want to ruin your day (it is Monday after all) let sleeping dogs lie. </p>
<p>The paucity of detailed reliable data to gage patient throughput is a significant hospital need, and I think a key justification for buying a system like StatCom&apos;s, that is not addressed in the survey. Having some quantitative market research as proof to this need would be something I&apos;d want if I was a patient flow software product manager.</p>
<p><span style="font-weight: bold;">Patient Care Methodologies</span><br />The other thing that struck me was the lack of any questions about patient care methodologies that create patient flow bottlenecks. Most hospitals are structured and managed based on industrial principles from 30 or 40 years ago. Back in the 1980s before DRGs and prospective reimbursement when hospitals had excess capacity, setting aside a fixed number of beds (and equipment) for specific categories of patients worked pretty well - excess capacity hid a multitude of sins. </p>
<p>As falling reimbursement wrung out excess capacity, the fundamental weaknesses of allocating fixed resources on the expectation that a certain consistent number of patients will utilize those resources became evident. In manufacturing, just-in-time management tools were used to lower costs. The fact is there are no just-in-time patients. Just like manufacturers learned that market demand can&apos;t be reliably forecasted, and implemented flexible manufacturing concepts, hospitals must move beyond rigid patient care strategies. Besides creating patient flow bottlenecks in units like critical care and telemetry, conventional care methodologies can result in unnecessary patient transfers (something else the survey didn&apos;t explore).</p>
<p>The most common example of a patient care methodology analogous to modern manufacturing processes goes by various names: variable acuity units, flexible monitoring, or universal beds. Whatever you call it, it means providing patient care in one on-service unit and not transferring the patient every time their acuity changes. Patient transfers are bad; each transfer adds a day to the patients LOS, and represents an opportunity for adverse events resulting from less than perfect patient hand-offs. Manufacturing has developed many techniques to be more flexible, like <a href="http://en.wikipedia.org/wiki/Cellular_manufacturing">cellular manufacturing</a>, <a href="http://www.valuebasedmanagement.net/methods_kaizen.html">kaizen</a>, the <a href="http://medicalconnectivity.com/categories/patientFlow/2005/06/07.html">Toyota Way</a>, <a href="http://www.lean.org/">LEAN</a> and <a href="http://en.wikipedia.org/wiki/Six_Sigma">Six Sigma</a> - and many of these tools have been adopted by innovative hospitals.</p>
<p>The best way to minimize critical care and telemetry as patient flow bottlenecks is through variable acuity units, where patients receive the most appropriate level of care in the lowest cost setting. You will never be able to match the number of critical care and telemetry beds to the exact number of patients who need them. You can waste money building too many of these high acuity beds - and don&apos;t forget that about 15% of the patients in your critical care and tele beds right now don&apos;t meet admit criteria and should be in other units. Or you can continue to go on ambulance diversion. A patient flow system like StatCom&apos;s can be a useful tool in implementing variable acuity care. Good acuity scoring tools like <a href="http://www.atstaff.com/">ClairVia</a> are also helpful.<br /><br style="font-weight: bold;"><span style="font-weight: bold;">Prognostications and Prevarications</span><br />Let me close by offering some predictions. Thankfully, most of these predictions are perfectly safe because any outcome can&apos;t be verified. First off, the StatCom survey will show that the two departments representing the biggest patient flow bottlenecks are critical care and telemetry. </p>
<p>I see solid growth and adoption for the patient flow application market. McKesson&apos;s <a href="http://www.mckesson.com/en_us/McKesson.com/Our+Businesses/McKesson+Provider+Technologies/Newsroom/McKesson+Announces+Definitive+Agreement+to+Acquire+Awarix.html">acquisition</a> of <a href="http://awarix.com/">Awarix</a> is further validation of anticipated growth. The most important justification for a solution like StatCom&apos;s is that you can&apos;t manage what isn&apos;t measured. The market right now is still an <a href="http://en.wikipedia.org/wiki/Crossing_the_Chasm">early adopter market</a> (that&apos;s marketing-speak for those wild eyed innovators who will try anything). The generation of products coming to market now represents a big improvement over earlier solutions. These systems still require certain enabling technologies to work effectively in hospitals run by anyone but Jack Welch. These applications will provide a plethora of useful data, across the enterprise. As the market matures, hospitals will better learn to pick the good patient flow applications and get better at wringing the most value from them. </p>
<p>Oh, and don&#226;&#8364;&#8482;t throw six or seven figure consulting contracts at the problem. The 80/20 rule says that you&#226;&#8364;&#8482;ll get 80% of the value from only 20% of the patient flow issues excruciatingly documented by the hoard of fresh MBA graduates who descend on your hapless staff. Empower an internal champion and find someone (maybe even a vendor) who can quickly find the bottlenecks with the biggest impact. Buy a patient flow application, and converge your patient flow findings with your software implementation targeting the &#8220;big bang&#8221; opportunities. You&apos;ll still spend six or seven figures, but most if it will be on a software application that will deliver real value for years - as opposed to the one-time shot of a big consulting gig.</p>
<p>As patient flow problems increase, hospitals will transition from boarding patients awaiting an inpatient room in the ED to placing them up on their on-service unit. There&apos;s lots of rational patient safety and financial reasons to do this, and the outrage and consternation evoked by such a change will eventually give way to reason. And don&apos;t get snowed by the &#8220;fire codes don&apos;t allow us to leave patients in hallways&#8221; excuse. They&apos;re in hallways in the ED, aren&apos;t they?</p>
<p>Finally, the federal government&apos;s double edged strategy for transforming health care (reduced reimbursement to drive change, and increased visibility of provider performance to increase quality) will eventually include public disclosure of ED waiting times, reporting of time on ambulance diversion, and statistics on the number of patients boarded. This will probably occur after vendors &#8220;cross the chasm&#8221; and the early majority of the hospital market starts to implement patient flow solutions. This visibility will eventually drive the market laggards to adopt. </p>
<p>Pictured right is the hospital illustration from StatCom&apos;s home page - I like the 8-bit retro graphic design.</p>
]]></content:encoded>
			<wfw:commentRss>http://medicalconnectivity.com/2007/10/08/patient-flow-recommendations-and-predictions/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Reference Website: bmesource.org</title>
		<link>http://medicalconnectivity.com/2007/10/01/reference-website-bmesourceorg/</link>
		<comments>http://medicalconnectivity.com/2007/10/01/reference-website-bmesourceorg/#comments</comments>
		<pubDate>Tue, 02 Oct 2007 01:07:42 +0000</pubDate>
		<dc:creator>Tim Gee</dc:creator>
		
		<category><![CDATA[Uncategorized]]></category>

		<guid isPermaLink="false">http://medicalconnectivity.com/2007/10/01/reference-website-bmesourceorg/</guid>
		<description><![CDATA[The site bmesource.org is a compendium of web sites with the stated goal of, &#8220;sharing knowledge across the biomedical technology design community.&#8221; The site was started at Stanford University. In 2003 they opened it up to additional university contributors.
I stumbled across the sites via my server logs that showed a visitor who came from bemesource.org. [...]]]></description>
			<content:encoded><![CDATA[<p>The site <a href="http://171.65.102.151/%7Ebmesource/Start">bmesource.org</a> is a compendium of web sites with the stated goal of, &#8220;sharing knowledge across the biomedical technology design community.&#8221; The site was started at Stanford University. In 2003 they opened it up to additional university contributors.</p>
<p>I stumbled across the sites via my server logs that showed a visitor who came from bemesource.org. The sight is pretty cool, check it out.</p>
]]></content:encoded>
			<wfw:commentRss>http://medicalconnectivity.com/2007/10/01/reference-website-bmesourceorg/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Home Use of Medical Devices Challenges FDA</title>
		<link>http://medicalconnectivity.com/2007/09/27/home-use-of-medical-devices-challenges-fda/</link>
		<comments>http://medicalconnectivity.com/2007/09/27/home-use-of-medical-devices-challenges-fda/#comments</comments>
		<pubDate>Fri, 28 Sep 2007 01:34:43 +0000</pubDate>
		<dc:creator>Tim Gee</dc:creator>
		
		<category><![CDATA[Uncategorized]]></category>

		<guid isPermaLink="false">http://medicalconnectivity.com/2007/09/27/home-use-of-medical-devices-challenges-fda/</guid>
		<description><![CDATA[
Medical Devices Today has a good post on potential safety and effectiveness issues surrounding medical devices where home use by patients is outside the scope if intended use. &#8220;Although manufacturers need FDA approval to market a device
over-the-counter directly to a patient or specifically for home use,
there are few restrictions on whether a physician can send [...]]]></description>
			<content:encoded><![CDATA[<p><img alt="Baxter-Syndeo" src="http://medicalconnectivity.com/gems/Blog%20Photos/Baxter-syndeo.jpg" align="right" border="0" height="239" hspace="4" vspace="4" width="200"></p>
<p>Medical Devices Today has <a href="http://www.medicaldevicestoday.com/2007/09/home-use-of-dev.html">a good post</a> on potential safety and effectiveness issues surrounding medical devices where home use by patients is outside the scope if intended use. &#8220;Although manufacturers need FDA approval to market a device<br />
over-the-counter directly to a patient or specifically for home use,<br />
there are few restrictions on whether a physician can send a patient<br />
home with a device that is not specifically labeled for use in the home.&#8221;</p>
<p>One of the biggest issues revolves around older devices that have been replaced and become hand-me-downs for home health. Concerns include:
<ul>
<li>Neither devices or directions for use not designed for patient use</li>
<li>Hand-me-down devices frequently missing directions for use</li>
<li>Patient purchased devices, e.g., after the  reimbursed rental period, end up getting &#8220;recycled&#8221; through eBay  - with no safeguards for proper maintenance, operation or directions for use</li>
<li>Proper distribution channel safeguards to ensure safety and effectiveness when sold retail or through other resellers</li>
</ul>
<p>Besides contemplating new regulations or legislation, the FDA is making the following responses:
<div style="margin-left: 40px;">
<p>Meanwhile, in the next six months FDA hopes to invite manufacturers<br />
to participate in its new online labeling repository for home-use<br />
devices. The voluntary repository, which will initially focus on<br />
infusion pumps, will give consumers access to the most up-to-date<br />
instructions for specific models. </p>
<p>The agency is also preparing to launch a sub-network of its MedSun<br />
adverse event reporting program called HomeNet. Participating home<br />
health agencies will be encouraged to report to FDA adverse events,<br />
including close-calls, related to devices used in the home setting. </p>
</div>
<p>Be sure to read the <a href="http://www.medicaldevicestoday.com/2007/09/home-use-of-dev.html">whole thing</a>. Pictured right is a Baxter Syndeo pump - perhaps something that might be used in the home?</p>
]]></content:encoded>
			<wfw:commentRss>http://medicalconnectivity.com/2007/09/27/home-use-of-medical-devices-challenges-fda/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Biomed Listserv Is Moving</title>
		<link>http://medicalconnectivity.com/2007/09/26/biomed-listserv-is-moving/</link>
		<comments>http://medicalconnectivity.com/2007/09/26/biomed-listserv-is-moving/#comments</comments>
		<pubDate>Wed, 26 Sep 2007 22:15:02 +0000</pubDate>
		<dc:creator>Tim Gee</dc:creator>
		
		<category><![CDATA[Uncategorized]]></category>

		<guid isPermaLink="false">http://medicalconnectivity.com/2007/09/26/biomed-listserv-is-moving/</guid>
		<description><![CDATA[Mike Kauffman&apos;s labor of love, the Biomed Listserv has moved. Once hosted by AOL, Mike&apos;s snapped up an Internet domain (www.bmetsonline.org) and is adding some new features to extend the email listserv. 
If you&apos;re already subscribed to the Biomed Listserv, Mike has already moved all the subscribers to the new system (thanks Mike!). If you [...]]]></description>
			<content:encoded><![CDATA[<p>Mike Kauffman&apos;s labor of love, the Biomed Listserv has moved. Once hosted by AOL, Mike&apos;s snapped up an Internet domain (<a href="http://bmetsonline.org/">www.bmetsonline.org</a>) and is adding some new features to extend the email listserv. </p>
<p>If you&apos;re already subscribed to the Biomed Listserv, Mike has already moved all the subscribers to the new system (thanks Mike!). If you want to subscribe, <a href="http://bmetsonline.org/Listserv.htm">click here</a>. Be sure to check out the <a href="http://bmetsonline.org/BTalkfaq.dwt">FAQ first</a>. Starting January, 2008 Mike will be charging list subscribers a modest annual fee - well worth the investment. </p>
]]></content:encoded>
			<wfw:commentRss>http://medicalconnectivity.com/2007/09/26/biomed-listserv-is-moving/feed/</wfw:commentRss>
		</item>
	</channel>
</rss>
