Dreaming of Flexible, Simple, Sloppy, Tolerant in Healthcare IT

I was recently browsing in the computer (nerd) section of the bookstore and ran across an old Joel Spolsky edited book: The Best Software Writing I.  Even though it's been about four years, good writing is good writing, and there is still a lot of insightful material there.

One of the pieces that struck a cord for me was Adam Bosworth's ISCOC04 Talk (fortunately posted on his Weblog).  He was promoting the use of simple user and programmer models (KISS -- simple and sloppy for him) over complex ones for Internet development.  I think his jeremiad is just as relevant to the current state of  EMR and interoperability.  Please read the whole thing, but for me the statement that get's to the point is this:

That software which is flexible, simple, sloppy, tolerant, and altogether forgiving of human foibles and weaknesses turns out to be actually the most steel cored, able to survive and grow while that software which is demanding, abstract, rich but systematized, turns out to collapse in on itself in a slow and grim implosion.

Why is it that when I read "demanding, abstract, rich but systematized" the first thing that comes to mind is HL7?  I'm not suggesting that some sort of open ad hoc system is the solution to The EMR-Medical Devices Mess.  But it's painfully obvious that what has been built so far closely resemble "great creaking rotten oak trees".

The challenge for the future of Healthcare interoperability is really no different than that of the Internet as a whole (emphasis mine):

It is in the content and the software's ability to find and filter content and in the software's ability to enable people to collaborate and communicate about content (and each other).

I would contend that the same is true for medical device interoperability. Rigid (and often times proprietary) systems are what keep devices from being able to communicate with one another.  IHE has created a process to try to bridge this gap, but the complexity of becoming a member, creating an IHE profile, and having it certified is a also a significant barrier.

Understanding how and why some software systems have grown and succeeded while others have failed may give us some insights. Flexible, Simple, Sloppy, Tolerant may be a dream, but it also might not be a bad place to start looking for future innovations.

Adam also had this vision while he was at Google: Thoughts on health care, continued (see the speech pdf):

... we have heard people say that it is too hard to build consistent standards and to define interoperable ways to move the information. It is not! ... When we all make this vision real for health care, suddenly everyone will figure out how to deliver the information about medicines and prescriptions, about labs, about EKGs and CAT scans, and about diagnoses in ways that are standard enough to work.

Also see the Bosworth AMIA May07 Speech (pdf) for how this vision evolved, at least for Google's PHR.

UPDATE (2/9/09): Here's a  related article: The Truth About Health IT Standards – There’s No Good Reason to Delay Data Liquidity and Information Sharing that furthers this vision:

We don’t have to wait for new standards to make data accessible—we can do a ton now without standards.  What we need more than anything else is for people to demand that their personal health data are separated from the software applications that are used to collect and store the data.

UPDATE (4/17/09): John Zaleski’s Medical Device Open Source Frameworks post is also related.

Use of an open-source framework approach is probably as good as any. As a management model, I don’t see it as being that much different from the way traditional standards have been developed. Open-source just provides a more ad-hoc method for building consensus. Less bureaucracy is a good thing though. It may also allow for the introduction and sharing of more innovative solutions. In any case, I like visions.

USB plug-n-play (plug-n-pray to some) may be a reasonable connectivity goal, but it does not deal at all with system interoperability. Sure, you can connect a device to one or more monolithic (and stable) operating systems, but what about the plethora of applications software and other devices?  This just emphasizes the need to get out of the “data port” (and even “device driver”) mind-set when envisioning communication requirements and solutions.

Posted in EMR, Google, HL7, Interoperability, PHR, Programming | Tagged , , , | 2 Comments

Programming Languages for the New Year

As the New Year approaches a software developer's idea of renewal is typically learning a new programming language.  I ran across the following post which provides some interesting alternatives to consider.

10 programming languages worth checking out:

Also, Dr. Dobb's has an article on functional programming languages: It's Time to Get Good at Functional Programming

Posted in Programming | Tagged , , , , , , , , | 2 Comments

Networked Medical Devices

If you work with networked medical devices, Tim's post Medical Device Networks Trouble Industry is a must-read.

In order to better illustrate the bigger picture I thought this diagram might help:

netmeddev

This summarizes the relationship between the major players involved with integrating medical devices into an enterprise network and highlights some points I think are important.

  1. Only medical device manufacturers have to be concerned with the FDA regulatory aspects of placing computing and networking components into a medical environment. I've previously discussed some of the regulatory and verification/validation issues with Connecting Computers to FDA Regulated Medical Devices.
  2. All of the players -- hospital IT, medical devices, and IT/EMR software vendors -- deal with the same commercially available hardware and software components. This is simply due to the economy of scale.  The medical industry isn't large enough create the quantities necessary to drive the cost out of most of these devices. We have to depend on the broader high-volume commercial marketplace  in order to reduce cost.
  3. The medical device industry is involved in standards development, but at the end of the day its the broader market adoption that drives down the cost for everyone (see point #2).  I think this is one of the main reasons why "the days of private medical device networks as we know them are over."
  4. FDA guidance and regulatory efforts in this area will always be in catch-up mode. As the technology and trends change they will be forced to evaluate the impact on patient safety after the fact. This is already happening -- as Tim points out (emphasis mine):

The bottom line here is that we can’t all look to the FDA to solve these issues that are the consequence of putting medical device systems on enterprise networks - when you do this, your enterprise network becomes part of a medical device.

Medical devices have been added to enterprise networks for years, yet IEC 80001 and the Medical Device Data Systems rule are still just drafts.

Some other thoughts:

  • Private Medical Device Networks: Wireless networks are more often private. For wired networks "logically separate private networks through the use of network switches and routers" is more the norm. Since Ethernet took over in the mid 90s (anyone remember token ring?) most hospitals have not allowed private in-wall wiring installations.
  • Enterprise Networks: One of the major challenges is just getting your private "logical" system installed on the hospital infrastructure. In addition to reliability, compatibility, routing, and bandwidth are just a few of the issues.  One of the troubling aspects of this from a regulatory point of view is that there is no way for a medical device manufacturer to test all of the possible configurations that may arise in the field. The sustaining engineering and network variability issues are related problems.
  • Hospital IT Culture: This is an issue that I have seen first-hand.  A previous medical device I worked on used an embedded POSIX compliant UNIX variant. We ran into several hospital IT departments that refused to approve the medical device purchase because their policy would only allow computers running certain versions of the Microsoft OS on their network. This happened quite a few years ago. I can only hope that the integration philosophies of hospital IT departments have become more enlightened since then.

UPDATE  (1/15/09): Here's another good article on this subject:  Smoothing the Rocky Path of Interconnected Medical Devices.

Posted in Medical Devices, Networking | Tagged , | 2 Comments

The 2008 Year in Ideas

The annual Year in Ideas New York Times Magazine issue is one of my favorites. Of the 58 ideas, only two are biomedical related:

Automated Anesthesia (McSleepy)

The Biomechanical Energy Harvester

There are also a couple of other medical ideas, but all are worth looking through.

The only software/high-tech gadget idea is an iPhone application: Bubble Wrap That Never Ends ("Infinite Pop Pop").

IMO the strangest of the lot is Carbon Penance which takes personal responsibility for climate change to a new level:

When it detects, via a special power monitor, that electric current levels have exceeded a certain threshold, the wireless device slowly drives six stainless-steel thorns into the flesh of your leg. “It’s therapy for environmental guilt,”...

No thanks!

Posted in General | Leave a comment

What makes a good programmer? Acceptance of meaningless rules and conclusions!

Boing Boing has this great post: Comfort with meaninglessness the key to good programmers.

Research in the UK on teaching computer science found three groups of students:

  1. People who answered the questions using different mental models for different questions.
  2. People who answered using a consistent model.
  3. People who didn't answer the questions at all.

Contrary to predictions that the more adaptive group (#1) would fair better, they found that the consistent group (#2) were more successful programmers.

Even better:

... single biggest predictor of likely aptitude for programming is a deep comfort with meaninglessness

Now I know why I enjoy programming so much.

Social science research is so much fun! As you might have expected,  xkcd has the perfect strip for this (hat tip: comment #6):

the_difference

Posted in Programming | Leave a comment

Typealyzer

Via Ayende, here's a cool text analysis site: Typealyzer. They should really work on their spelling and syntax though (I made corrections). Here are the results for this site:

INTJ - The Scientists

INTJ

The long-range thinking and individualistic type. They are especially good at looking at almost anything and figuring out a way of improving it - often with a highly creative and imaginative touch. They are intellectually curious and daring, but might be physically hesitant to try new things.

The Scientists enjoy theoretical work that allows them to use their strong minds and bold creativity. Since they tend to be so abstract and theoretical in their communication they often have a problem communicating their visions to other people and need to learn patience and use concrete examples. Since they are extremely good at concentrating they often have no trouble working alone.

The second part of the analysis is this:

This shows what parts of the brain that were dominant during writing.

Who would have guessed? And no gelled electrodes, magnetic fields, or X-rays were involved! 🙂

Posted in General | Tagged | Leave a comment

Agile Stumbling?

James Shore has an interesting post, The Decline and Fall of Agile, that has generated a lot of good discussion over the last couple of weeks.

I've seen a shift in my business over the last few years.

I can't disagree with the assessment of James' own business trends (or his colleagues) . But I have to wonder how well his anecdotal sample extrapolates to the rest of the Agile industry?  Without some real numbers to back it up, how can he claim that Agile is either declining or will fail?

But those hundreds of successes will be drowned out by the thousands of failures.

That statement isn’t evidence of a trend; it’s a prediction of the future based to how he happens to be feeling right now. It would be nice if James (or anyone else) could provide some real evidence that the Agile movement is actually in decline -- or at least it's success rate relative to the alternatives, e.g. Waterfall.

Some more views on this are here:
James Shore: The Decline and Fall of Agile
Thoughts on the Decline and Fall of Agile
The Decline and Fall of Agile and How Scrum Makes it Hurt More

These are valuable discussions for developers and managers that don't have direct personal experience with Agile methodologies but might be considering using them in the future.  It's clear (to me anyway) that when it comes to software development management, the process is a difficult one no matter what path you take.

Posted in Agile | 1 Comment

Microsoft Research at PDC2008

Most of the press coming out of PDC2008 were all the cool new product development technology announcements. What you probably don't appreciate is the depth and breadth of the Microsoft research effort that is really the foundation for many of these products.

The Day Three PDC Keynote by Rick Rashid (and others) is over 90 minutes long, but is worth a look.  It's all fascinating stuff.

Hat tip: Dr. Neil's Notes: Day Three PDC Keynote: Microsoft Research Magic

Posted in Microsoft, Technology | 1 Comment

Keeping Your Own Health Chart, Online

The New York Times has a piece today that features the Zuri, Healthvault, and Google Health:

Keeping Your Own Health Chart, Online

The article discusses a number of uses for this kind of combined (medical device plus PHR) functionality.  Besides the obvious, it's interesting that clinical trial matching (TrialX) is also mentioned.

User control of on-line health information has many hurdles to overcome.  Even with adequate security:

First, however, patients will have to become comfortable placing medical data like readings from home tests online.

Posted in Medical Devices, PHR | Leave a comment

EEG-based Lie Detector Convicts Murder Suspect in India

India’s Novel Use of Brain Scans in Courts Is Debated details how the Brain Electrical Oscillations Signature (BEOS) test  was used to convict a 24 year old woman of murder. It was reported in July (This brain test maps the truth) that the BEOS test was found admissible in court in two murder cases.

I've discussed Mind Reading Software a number of times in the past, including Brain Fingerprinting (also see here).  A more thorough analysis of this type of EEG technology, BEOS, and fMRI can be found here: Is Guilt Written in the Brain? There are several good links to scientific papers on the subject, and it also hits the nail on the head with this conclusion about the murder conviction:

At this point this is the equivalent of using pseudoscience in the courtroom. This is as irresponsible as basing a verdict on the ramblings of a psychic - except that it comes with the trappings of science and legitimacy.

(Hat tip: Medgadget)

UPDATE (9/20/08):

This is related, but not worth another post: The Army's Totally Serious Mind-Control Project (Hat tip: Slashdot). The goal is to "lead to direct mental control of military systems by thought alone." That's pretty ambitious. They reference the Emotiv headset, but the whole concept of using EEG-based systems for any type of control purposes is still a stretch. Fortunately, the investment is small -- the Army probably spends more than $4 million a day on toilet paper.

Posted in EEG, fMRI | 1 Comment