eVent Medical Ventilator Incorporates Web Server

Posted by Tim Gee on Oct 19, 2007 in Company Profiles, Real Time Location Systems | 0 comments

The ventilator market is an interesting one – there are many more vendors than in most other product categories, and greater product differentiation between vendors. This is also a product category where hospitals have, for the most part, been unsuccessful in standardizing on a single vendor.

I came across an interesting ventilator vendor the other day, eVent Medical. Their adult and neonatal ventilators are pictured right. Key features include:

• Invasive and noninvasive ventilation
• 5 hour battery life
• Emergency backup compressor
• Integral nebulizer
• Heliox gas support

What intrigued me about their product is the optional web server. The product has both serial and Ethernet network connectivity – obviously, a network connection is require to serve web pages. Remote surveillance has become important as ventilated patients are increasingly placed outside of critical care areas where nurse to patient ratios are lower and the patients covered by a respiratory therapist could be sprinkled widely across a hospital.

This feature suggests certain product architectures that could perhaps support some truly innovative and compelling patient safety and workflow automation features. I hope to learn more soon.

Hospital Quality Reporting Reveals Stark Differences in Mortality

Posted by Tim Gee on Oct 19, 2007 in Real Time Location Systems | 0 comments

The Kaiser Family Foundation reports that the latest HealthGrades Hospital Quality in America study shows that Medicare patients in the “highest-ranked U.S.
hospitals are 71% less likely to die than those who receive care in the
lowest-ranked facilities.”

The study is available on the HealthGrades home page under “research” – download your copy now.

The Value of Unique Device Identification

Posted by Tim Gee on Oct 18, 2007 in Patient Safety | 0 comments

Is there a need to better track the use of medical devices? You bet. Besides tracking implantables for post market surveillance and recalls, tracking medical devices used at the point of care can reduce the risk of infections like methicillin-resistant Staphylococcus aureus (MSRA) through physical contact and cross contamination. There are no national hospital reporting requirements, and few state requirements for these infections. This story in the Baltimore Sun reports on a news study released by the CDC on MSRA infections:

“This is the first time that we’ve been able to measure the number of infections,” said the study’s lead author, Dr. R. Monina Klevens, an epidemiologist with the federal Centers for Disease Control and
Prevention. “We were surprised that the rates were so high. It’s a call to action.”

Industry consultant Brad Sokol developed a Medical Device Pedigree for tracking the use of devices and related patient outcomes last year. You can get the low down on Sokol’s pedigree from this presentation (pdf) on the FDA web site.

His theory predicted 13,000 to 26,000 thousand deaths from infection caused by contaminated medical devices and instruments. In the new study, “Of those infected with MRSA, almost 1,600 died, about 18 percent of the total. Extrapolating those figures to the entire U.S.
population, researchers said some 94,000 people might be infected, with 19,0000 deaths.” It would seem that Sokol was right on target.

The paucity of quality and outcomes reporting by providers is slowly changing as hospital and physician data is published by CMS and other federal agencies, state governments, hospitals themselves, and others. But we have a long way to go.

Much of the debate about Unique Device Identification (what the industry refers to as “UDI”) for medical devices is misdirected. There is too much talk about needing a unique identifier, as if the law did not already mandate one (see this, and here).

MDDI magazine ran a story that revealed the real UID agenda, From Information Silo to Bridge: The State of UDI. The real issue here is the need to track medical devices – especially implanted devices – to determine their performance. From the MDDI story:

When it comes to devices, comparisons with other products are inevitable. For example, the Advancing Patient Safety Coalition recently compared medical devices to peanut butter. Specifically, in a letter to congressional members dated June 18, 2007, the  coalition stated, “We can simply and quickly identify each and every jar of peanut butter that might have salmonella and remove them from store shelves in hours, but we cannot do that reliably today with potentially life-threatening defective medical devices.” Similarly,
during a 2006 CDRH public meeting, Larry Kessler said that the medical device industry is “probably a decade or more behind the grocery industry” in terms of product tracking.

By equating medical devices with peanut butter, the authors imply it is the device vendor who is responsible for this sorry state of affairs. In fact, the guilty party is the equivalent of the grocery industry, health care providers.

There is no doubt that better tracking of medical devices would improve recalls, provide better post-market surveillance to better reveal safety issues, and reduce avoidable infections. But we don’t need some new fangled UID standard affixed to medical devices to do it. Here’s what’s really missing:

1. A mandate that providers track, record, and report the use of all medical devices (and associated clinical outcomes data) without exception,
2. A repository where data is aggregated across providers, devices and device vendors, and
3. Someone to analyze this data and report it to the public, providers, patients, and vendors for appropriate responses and follow up actions.

This makes forcing device vendors to replace the currently mandated unique identification (you’ve probably heard of them, serial numbers) with a “new” and “improved” UID seem like the side show that it really is. Let’s assume that AdvaMed doesn’t muster the political leverage to forestall the UID, and in a few years some standards body promulgates a new UID standard. Okay, the easy part is done, now for the hard stuff.

• Who’s going to mandate that providers do all this tracking and reporting?
• Who pays for all the fancy new IT and labor required to track and report this data?
• What entity(s) will assume responsibility for maintaining this repository of medical device usage – and outcomes?
• Who will enforce the implementation and conformance of this reporting by providers – and what penalties will be incurred for non-compliance?
• Who’s going to manage the recall communications and follow up?
• Who’s going to assess post market surveillance data and issue recalls? (That’s pretty easy, the FDA would clearly handle this – but they’ll need more money.)
• What about patient privacy, who will be responsible for maintaining it, and will patients be able to opt out?

The scope of the UID system that’s required to achieve the benefits many have attributed to this “great leap forward” becomes more clear. In fact, you could implement all the tracking and gain the very same patient safety improvements using the industries current UID, vendor serial numbers.

I should also note that vendors are currently required to maintain device history records that would benefit greatly from data held by providers (patient data for implants, near miss events, outcomes data) that is currently unreported. A simple mandate requiring providers to report this data to device vendors, and an open source software project driven by a foundation or university is a more direct and efficient solution.

All this really doesn’t have much to do with a fancy new identification number, does it?

Pictured right are some blood transfusion ID labels from the UK Blood Transfusion & Tissue Transplantation Services web site. The tracking of blood products might serve as a benchmark for UDI efforts.

UPDATE: From iHealthBeat, “Sen. Edward Kennedy (D-Mass.) on Thursday sent a letter to HHS Secretary Mike Leavitt urging the agency to finalize rules to implement the Patient Safety and Quality Improvement Act of 2005, Health Data Management reports.”

And this from FierceHealthcare:

Over the past week or so, the mainstream news media have crackled with the news of staph infections (including MRSA) found in  community schools. Prompted by this, Rep. Tim Murphy (R-PA) has filed a bill tha would require all hospitals in the U.S. to report infection rates t HHS. Under the terms of the bill, HHS would make such information available publicly on its website.Such a measure would trump existing infection tracking underway in the states. Right now ninetee states require infection reporting, but not all make the information public. (Murphy’s home state of Pennsylvania does make hospital-acquired infection reports available at www.phc4.org.)

Microsoft HealthVault: Device Connectivity

Posted by Tim Gee on Oct 15, 2007 in Company Profiles, Healthcare IT, Real Time Location Systems | 2 comments

The HealthVault (HV) beta was launched October 4, 2007. Between the confusion surrounding the launch and work, I've tried to gather some thoughts and get some questions answered.

The launch was a classic Microsoft launch: big, dramatic, expensive, and well executed, right down to the goody bags (you had to be there to get one, so I missed out). Typical with such events, naysayers were out in force, and there was a bit of confusion. You can also find some good information on the big picture of HV from Vince Kuraitis and Enoch Choi.

Perhaps the most confusion around HV is whether or not it is a personal health record (PHR). Many of the “news stories” that recycled the HV press release referred to HV as a PHR. A few, Vince and Enoch among them, noted that HV is in fact not a PHR. From what I and others can see, there is very little in the way of a user interface that would allow patients to maintain and manage a PHR.

According to one Microsoft executive I talked with, HV is a “platform” that's intended to be used by other applications, and is not a PHR. He reported that Microsoft's taken a more consumer focused approach, surrounding them with their information so they can share their health data with whom they wish. So, the absence of a robust PHR user interface is apparently a conscience
decision on Microsoft's part. Nor would it be to awfully difficult to
provide one should they move in that direction.

The published API, data interoperability via numerous standards, data storage, security, authentication, and the patient's ability to control their data creates a veritable Swiss Army knife for health data. Microsoft has tried to create a new kind of platform that's ideal for health information. They certainly have some ideas about how it can be used (and currently monetized – by ad revenue), but my contact acknowledged that they expect partners and consumers to take the platform in unforeseen directions. As a beta product, there are many unknowns beyond the mid term horizon.

Device Connectivity
Microsoft sees devices for health and fitness and chronic disease management as a big piece of HV. Medical devices are integrated into HV via the Connection Center (CC). The HV CC includes a device driver (specified by Microsoft and developed by the device vendor) that integrates a remote monitoring device into a Windows PC, and the CC application that runs on the PC and integrates with the HV web site. Microsoft has an SDK for creating a serial device driver for connecting these devices to Windows PCs, along with the HV CC sync program that allows consumers to capture, review and share data via HV. There do not seem to be any data editing capabilities in HV CC – more on this in an upcoming post.

My contact used the digital camera analogy when describing what this might mean for remote monitoring devices. In the early days, digital cameras came with their own proprietary software that allowed you to connect your camera to a computer and download pictures. As the technology matured, cameras adopted the USB standard and now plug and play with PCs.

This ubiquitous connectivity sounds great, but Microsoft is not anything like the USB Implementers Forum. While their device to PC SDK is open, the software on the PC is not. In fact, one wonders how HV will play out against another medical device group, the Continua Health Alliance.

Remote monitoring systems have 4 components: the medical device, a gateway device for aggregating data from multiple devices and moving that data over a network to an application, the application that manages the patient data (which usually runs on a server on the Internet), and some sort of integration with EMR/billing system(s). Continua is working to provide multi vendor plug and play interoperability between each of these components. Microsoft is not a member of Continua and is providing an open, but proprietary means to link devices with server applications – turning the Windows PC into a virtual gateway.

The HV CC turns your Windows PC into a remote monitoring gateway. The application can aggregate data from multiple devices and push that data into your HV account. To then get the data into the remote monitoring application it is transferred (automatically?) from HV to a compatible application.

Most remote monitoring gateway devices pull data from remote monitoring devices and push it directly into the target application. In fact the data may not be “ready” for third party applications until it is processed by the target application – more on this issue in an upcoming post. Certainly Internet-based remote monitoring server applications can leverage HV to provide interoperable data between other applications like physician EMRs.

Will vendors implement both Continua and HV connectivity? The fact that Continua validated interoperable products won't be available until the end of 2008 is an issue than you might think. Any vendor starting development now will take at least that long to finish their product. So they must make the decision whether to base their new product on Continua, HV, or both. (Hint: this is not a “o brainer” question.)

Closing Thoughts
Regardless of those that claim Microsoft “won round one” against Google, there is no first mover advantage in any of this. In fact, follow on solutions will likely benefit greatly from Microsoft's very public experience. Other big vendors or efforts mentioned in the press include Google, Cisco, and Dossia (which includes Intel, Wal-Mart and other big employers). I talked about non health care companies entering the health care market before. This is not an easy transition; it will take longer and cost a whole lot more that most anticipate.

Check back throughout the week; I'll have some follow on posts on adoption, network effect and other topics.

Pictured right is Bill Gates, from a PhotoShop contest on Gizmodo, that tickled my fancy.

42 Questions HHS Might Ask During a HIPAA Audit

Posted by Tim Gee on Oct 11, 2007 in Standards & Regulatory | 0 comments

Some recent projects have touched on HIPAA lately and I thought I’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 conducted by the office of the inspector general at the U.S. Department of Health and Human Service (HHS) and is being seen by some in the health care industry as a precursor of similar audits to come at other institutions.

Neither Piedmont nor HHS officials have publicly confirmed the audit or spoken about it. That silence has sparked considerable curiosity about why Piedmont was targeted as well as the scope of the audit and the kind of information HHS was seeking.

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:

1. Establishing and terminating users’ access to systems housing electronic patient health information (ePHI).
2. Emergency access to electronic information systems.
3. Inactive computer sessions (periods of inactivity).
4. Recording and examining activity in information systems that contain or use ePHI.
5. Risk assessments and analyses of relevant information systems that house or process ePHI data.
6. Employee violations (sanctions).
7. Electronically transmitting ePHI.
8. Preventing, detecting, containing and correcting security violations (incident reports).
9. Regularly reviewing records of information system activity, such as audit logs, access reports and security incident tracking reports.
10. Creating, documenting and reviewing exception reports or logs. Please provide a list of examples of security violation logging and monitoring.
11. Monitoring systems and the network, including a listing of all network perimeter devices, i.e. firewalls and routers.
12. Physical access to electronic information systems and the facility in which they are housed.
13. Establishing security access controls; (what types of security access controls are currently implemented or installed in hospitals’ databases that house ePHI data?).
14. Remote access activity i.e. network infrastructure, platform, access servers, authentication, and encryption software.
15. Internet usage.
16. Wireless security (transmission and usage).
17. Firewalls, routers and switches.
18. Maintenance and repairs of hardware, walls, doors, and locks in sensitive areas.
19. Terminating an electronic session and encrypting and decrypting ePHI.
20. Transmitting ePHI.
21. Password and server configurations.
22. Antivirus software.
23. Network remote access.
24. Computer patch management.

You’ve got that all documented, with training records, right? There was more.

1. Please provide a list of all information systems that house ePHI data, as well as network diagrams, including all hardware and software that are used to collect, store, process or transmit ePHI.
2. Please provide a list of terminated employees.
3. Please provide a list of all new hires.
4. Please provide a list of encryption mechanisms use for ePHI.
5. Please provide a list of authentication methods used to identify users authorized to access ePHI.
6. Please provide a list of outsourced individuals and contractors with access to ePHI data, if applicable. Please include a copy of the contract for these individuals.
7. Please provide a list of transmission methods used to transmit ePHI over an electronic communications network.
8. Please provide organizational charts that include names and titles for the management information system and information system security departments.
9. Please provide entity wide security program plans (e.g System Security Plan).
10. Please provide a list of all users with access to ePHI data. Please identify each user’s access rights and privileges.
11. Please provide a list of systems administrators, backup operators and users.
12. Please include a list of antivirus servers, installed, including their versions.
13. Please provide a list of software used to manage and control access to the Internet.
14. Please provide the antivirus software used for desktop and other devices, including their versions.
15. Please provide a list of users with remote access capabilities.
16. Please provide a list of database security requirements and settings.
17. Please provide a list of all Primary Domain Controllers (PDC) and servers (including Unix, Apple, Linux and Windows). Please identify whether these servers are used for processing, maintaining, updating, and sorting ePHI.
18. Please provide a list of authentication approaches used to verify a person has been authorized for specific access privileges to information and information systems.

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’ve noted before, biomed departments go through an audit like this as part of Joint Commission accreditation.

I would recommend that IT work with biomeds to make sure your medical devices can pass this same audit. These devices would include:

• PACS
• Blood bank
• 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
• Patient care device systems like “smart” infusion pumps, patient monitoring systems, networked ventilators – again any medical device connected to networked computers
• Medical device systems that provide remote access to users (that includes most of the above)
• Medical devices whose vendors provide remote service and support via the Internet or dial-up POTS

Have fun! Pictured right is the badge you’ll see when they visit.