• TPD’s List of iPhone Applications (73 by my count)
• 100 Awesome iPhone Apps for Med Students and Doctors
• 12 iPhone : EMR , PHR and Patient Trackers applications
• Top iPhone Apps For Health Pros, Patients

Update (11/3/09):

There’s an entire Web Site devoted to this subject:

iPhone Medical & Health Apps: news, reviews, trends

Hat tip: John Zaleski

Talking to DC

Hat Tip: Joel on Software

Also see Dreaming of Flexible, Simple, Sloppy, Tolerant in Healthcare IT and Liberate the Data!

But by 2020, when a vast majority of American health providers are expected to have electronic health systems, the data mining component alone could generate sales of up to $5 billion…

The magnitude of data needed to generate that kind a revenue is significant.  The likelihood that “de-identification” of someone’s health information will occur is very high.  “Anonymized” Data Really Isn’t points out the same thing that the NYT article does:

Computer scientists over the past fifteen years show that it is quite straightforward to extract personal information by analyzing seemingly unrelated, “anonymized” data sets.

The demand for the secondary use of health data (and here) is high because it is believed it will

Significantly improve the quality of patient care and offers the promise of even greater benefits in the future.

Many feel that use of secondary health information should be regulated by the government.

Here’s a good overview that covers many health data secondary use issues: Toward a National Framework for the Secondary Use of Health Data: An American Medical Informatics Association White Paper.

UPDATE (10/20/09): Also see the Wired article Medical Records: Stored in the Cloud, Sold on the Open Market.

• Modern software development tools and technologies require a significant learning curve.
• Development methodologies (like Agile) exist for managing complexity, but do not reduce the load of these technologies.
• In the last decade there has been no “Next Big Thing”, like Access was in the 90s.

What’s most interesting to me is:

We are in desperate need of simplicity in this industry. Whoever gets that, and gets it right, defines the “Next Big Thing”.

What’s true in the broader software world is also generally true in Healthcare IT.  In HIT there has never been an Access equivalent, just a lot of pieces and parts trying unsuccessfully to work together.

The need was touched on in Liberate the Data!.  Simplicity is desperately needed in order to create the “First Big Thing” for HIT interoperability.

UPDATE (10/14/09):  More commentary:

• Haacked, but not content; agile still treats the disease
• Response: “Agile is treating the symptoms, not the disease” by Ted Neward
• Time for simplicity?

I left work a little early because of the Packer-Viking game (MNF starts at 5:15 on the West Coast).  As I approached our Condo complex I saw smoke bellowing over the roofs. My wife had also just gotten home and we watched with amazement the canyon below going up in flames no more than 25 yards from our patio.

A neighbor had called 911 a few minutes before, but the 15 or so minutes prior to the SDFD arrival was tense. The fire spread amazingly fast. Large shrubs literally exploded into flames. The wind was blowing pretty hard in our direction, but seemed to wane and shift a little, which slowed its progress some.

We collected photos and valuables and got them in the car, ready to escape.

Fortunately, the SDFD came to the rescue in time. A fire helicopter did a couple of water drops, but it was the firefighters that saved the day.

Wow, close call!

I better get back to the second half. Go Pack!

UPDATE: Oh well. Brett and the Vikings will be at Lambeau on Nov. 1. It’s a long season…

Medical Data in the Internet “cloud”:

• (part 1) – Data Safety
• (part 2) – Data Security
• (part 3) – Data Privacy

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

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.

… 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:

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

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();

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):

Process.Start(Application.ExecutablePath);
Environment.Exit(0);

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.

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?