Archive for September, 2009

Medical Data in the Cloud

Saturday, September 26th, 2009

secure_documentI just ran across a three-part series of articles by Practice Fusion:

Medical Data in the Internet “cloud”:

Being an EMR in the cloud requires Practice Fusion to address these issues in depth. If you're thinking about putting health information in the cloud like I've previously discussed, these articles are worth a careful read.

Hat Tip:  Healthcare IT News

UPDATE (10/1/2009):

Some commentary on the Practice Fusion EHR:  Cloud based EHRs – a response to PracticeFusion.

UPDATE (10/5/2009): EMR Vendor Practice Fusion’s CEO Interview

Access to Medical Data: Are PC Standards and PHRs (You) the Answer?

Tuesday, September 22nd, 2009

Dana Blankenhorn's article Give medicine access to PC standards makes some good points about the medical device industry but (IMHO) misses the mark when trying to use PC standards and PHRs as models for working towards a solution.

I'll get back to his central points in a minute. One thing I find fascinating is the knee-jerk reaction in the comments to even a hint of government control.  How on earth can someone jump from "industry standard" to a "march towards socialism"? We saw the same thing at this summer's town hall meetings and in Washington a couple of weeks ago.  The whole health care debate is just mind boggling!

Anyway, let's focus on the major points of the article. First:

Every industry, as its use of computing matures, eventually moves toward industry standards. It happened in law, it happened in manufacturing, it happened in publishing.

It has not happened, yet, in medicine.

Very true.  In the medical device world, connectivity and interoperability are hot topics. A couple of recent posts -- Plug-and-Play Medicine and Medical Device Software on Shared Computers -- point out the significant challenges in this area.  In particular, the development and adoption of standards is a very intensive and political process. But where's the incentive for the industry to go through this? Dana's comment addresses this (my emphasis):

The role I like best for government is in directing market incentives toward solutions, and not just to monopolies or bigger problems.

The reason health care costs jump every year is because market incentives cause them to. Those incentives must be changed, but the market won't by itself because the market profits from them.

Only government can transform incentives. ...

Like it or not, this may to the only way to push the medical industry to do the right thing.  But those other industries didn't need government intervention in order to create their standards.  Using PC (or other industry) standards as a model for facilitating medical data access just doesn't work.  The health industry will have to dragged to the table kicking and screaming, and the carrot (or stick) will have to be large in order for them to come to a consensus.

Second, I don't see the relationship between the use of PHRs and the promotion of standards.

By supporting PHRs, you support your right to your own data. You support liberating data from proprietary systems and placing it under industry standards.  You support integrating your health with the world of the Web, and the benefits such industry standards can deliver to you.

Taking responsibility for your own health data is great, but both Microsoft HealthVault and Google Health are proprietary systems.  Just because your data is on the Web doesn't make it any more accessible.  And even if one of these PHRs did became an industry standard, it would have very little impact on how EMRs communicate with each other or medical devices in general.

There are no easy answers.

Plug-and-Play Medicine

Sunday, September 20th, 2009

The MIT Technology Review article Plug-and-Play Medicine claims that:

... a Boston research group has come up with a software platform for sharing information among gadgets ...

Uh, what software platform? I discussed the MD PnP program a couple of years ago. Other than the Integrated Clinical Environment (ICE, ASTM F2761:2009) standards work I don't see a lot of progress, let alone software to look at.  The draft ASTM standard (Dec-2008) is still just a shell. The overall model structure makes sense, but the models themselves are not described in any detail (that I could find anyway).

I have a lot of respect for academic endeavors, but creating a comprehensive standard for something as multidisciplinary and complicated as medical device connectivity will not be an easy task.   I once participated in an ASTM standard that was limited to a single communications protocol, and it took years to finalize.  Developing models for how systems behave and interact is at a level of complexity that I'm not sure can ever really be standardized (how do you nail down a moving target?).

A good example is HL7 V3 RIM (Reference Information Model).  RIM has been under development for more than 10 years and as HL7 RIM: An Incoherent Standard (warning: PDF) points out, many mistakes have been made.  These issues may partially explain the woeful rate of HL7 V3 adoption.

The other thing HL7 V3 shows is the magnitude of work required in these standards efforts. The MD PnP group understands this and that standards are just part of the solution. The slide from here (warning: PDF) summarizes this well:

PnP

Unfortunately, the devil is in all these messy details and is the reason why plug-and-play medicine is still a long way off.

Hat tip: Mike Attili

A .NET Application that Never Dies

Saturday, September 12th, 2009

29392-Live_forever_-sfullJeremy's Graceful Shutdown Braindump should really include another use case. How do you create a .NET application that never shuts down? Ever!

This  is a common scenario for closed systems that only allow the user to interact with a predefined set of applications.  In other words, the user is never able to utilize any of the operating system functionality. In particular, they can not install new applications or update any software components.

This situation is related to the issues discussed in Medical Device Software on Shared Computers. Creating a closed Windows-based system is not an easy task. For our XP Embedded system here are some of the considerations:

  1. Prevent booting from a peripheral device (CD-ROM, USB stick, etc.)
  2. Prevent access to the BIOS so that #1 is enforced.
  3. Prevent plug-n-play devices from auto-starting installers.
  4. You can not run Explorer as the start-up shell -- no desktop or start menu.
  5. Prevent Ctrl-Alt-Del from activating task manager options.
  6. Disable the Alt-Tab selection window so the user can not switch application focus.
  7. Ensure that the primary user interface application is always running.
  8. All UI components must exit without user interaction when the system is powered down.

One of the challenges for .NET applications is how to handle unexpected exceptions. What you need first is a way to catch all exceptions.  OK, so now you know your program is in serious distress. You may be able to recover some work (a la a "graceful shutdown"), but after that it's not a good idea keep the application running.

That means you have to restart the program. For a WinForm application one option is:

Application.Restart() essentially calls Application.Exit() which tries to gracefully shutdown all UI threads.   The problem with that is the application may appear to be hung if you have background worker threads that are monitoring hardware devices that are not currently responding.

Another issue is when the .NET application is doing interop with COM components.  I've seen situations where all of the managed threads appear to exit properly via Application.Exit() but an un-managed exception (and error window) still occur.  This behavior is unacceptable.

The way to ensure that the application restarts properly (simplified):

The Environment.Exit() call is harsh, but it is the only way I know of that guarantees that the application really exits.  If you want a Windows Application event log and a dump of your application you can use Environment.FailFast() instead.

UPDATE (9/19/09): I ran across a post about COM object memory allocation in mixed managed/unmanaged environments: Getting IUnknown from __ComObject. As this article exemplifies, debugging COM objects under these circumstances is a real pain in the butt.  We used strongly-typed managed wrappers for our COM objects. Besides a .NET  memory profiler we just monitored overall allocations externally with Process Explorer. It may be undocumented and fragile, but at least it's good to know that there is way to dig deeper if you need to.

Medical Device Software on Shared Computers

Monday, September 7th, 2009

ECG PCThe issues raised in Tim's post Running Medical Device Software on Shared Computers literally opens Pandora's box. Installation of medical device software on general purpose computers is an intractable problem.

It's very similar to the complications associated with Networked Medical Devices, except worse.  An FDA approved device in a changing network environment is one thing.  Software that controls a medical device on a PC that is open for the user to install operating system upgrades, applications, and other device drivers is a recipe for disaster.

I don't care how obsessed a vendor is, there is no way for a medical device manufacturer to verify proper operation for all possible hardware and software environments.

With today's PC architectures, the highest risk area is at the device driver level. Running multiple devices that require even modest I/O bandwidth can cause interference that could result in lost or significantly delayed data. This is especially true with Windows XP or Vista that do not inherently provide any real-time data processing capabilities.

I think the best strategy is to provide stand-alone medical devices that have no dependencies on the PC hardware and software that may be available for down-stream data processing and display. This not only reduces compatibility risk, but it can also address mobility issues. With miniaturization and wireless capabilities, the medical device can now travel with the patient.

Also, with Pandora's box safely closed, solving the networked medical device issues suddenly feels manageable.

UPDATE (9/15/09): Here's an interesting take on this subject from the consumer perspective: Should Medical Devices Multitask?

2009 Ultimate Developer and Power Users Tool List for Windows

Wednesday, September 2nd, 2009

This is a great list. I linked to it in 2007, but somehow forget in 2008. Anyway, there's probably at least one tool you may not have seen before that would be worth trying out.

Scott Hanselman's 2009 Ultimate Developer and Power Users Tool List for Windows

Oh, and read through the comments. Everyone has their own favorites, and opinions.