Archive for the ‘Interoperability’ Category

« Older Entries
Newer Entries »

A Medical Device Gateway Data Standard?

Wednesday, November 18th, 2009

The Wipro OEM medical device gateway press release makes it all seem so easy (my highlight):

The device, consisting of interfaces that can feed-in data such as blood pressure, pulse rate, ECG reading and weight from the respective devices, is connected to the gateway that would format it into standard patient information and transmit it to either public health data platform such as Google Health or to private platforms like Microsoft Health Vault.

What exactly is "standard patient information"?  Maybe they've finally developed the magic interoperability bullet.  Yeah, right!  I'm sure companies like Capsule see these kind of claims all the time.  Statements like these are unfortunate because they give the impression that health data interoperability is a given. Of course we know that is not the case.

Also, since when is Google Health a public health data platform?

Hat tip: Avantrasara

UPDATE (11/19/09):  Wipro ties up with Intel for rural medical solutions

Tags:
Posted in Google, Interoperability, Medical Devices, Microsoft, PHR | 1 Comment »

Standards should be as Simple and Stupid as Possible

Saturday, October 31st, 2009

Great post by Adam Bosworth:

Talking to DC

Hat Tip: Joel on Software

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

Tags:
Posted in Interoperability | 1 Comment »

The Desperate Need for Simplicity

Tuesday, October 13th, 2009

Ted Neward's article "Agile is treating the symptoms, not the disease" touches on several important points about the software industry.

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

Tags:
Posted in Agile, Interoperability, Programming | No Comments »

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.

Tags:, ,
Posted in EMR, Google, Interoperability, Medical Devices, Microsoft | 1 Comment »

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

Tags:, , ,
Posted in HL7, Interoperability, Medical Devices | 1 Comment »

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?

Posted in FDA, Interoperability, Medical Devices, Networking | 8 Comments »

Inaugural Medical Device Connectivity Conference and Exhibition

Thursday, August 27th, 2009

meddeviceconn-conf

Tim Gee has put together an impressive conference. It's happening Sept. 10-11, 2009 in Boston. Unfortunately, I will not be able to attend. Hopefully Tim and others will be able to provide highlights from the many interesting topics.

Here's a condensed list of the agenda:

Day 1:

MEDICAL DEVICE  CONNECTIVITY IN HEALTH CARE: WHERE ARE  WE, WHERE ARE WE GOING, AND HOW DO WE  GET THERE?  Tim Gee, Connectologist & Principal, Medical  Connectivity Consulting

CONNECTING  OPERATIONAL AND STRATEGIC PERSPECTIVES  Julian M. Goldman, MD, Medical Director of Biomedical Engineering, Partners HealthCare System, Director,  CIMIT Program on Interoperability and Medical Device Plug-and-Play Interoperability Program, Massachusetts General Hospital

INDUSTRY STANDARDS  (FORMAL AND DE FACTO) IN CONNECTIVITY Charles (Chuck) Parker, Executive Director, Continua Health Alliance

PANEL DISCUSSION: INDUSTRY STANDARDS – WHICH STANDARDS WILL BE ADOPTED AND WHY?

IMPACT OF PROPOSED FDA RULE ON MEDICAL DEVICE DATA SYSTEMS William A. Hyman, ScD, PE, Professor, Department of Biomedical Engineering, Texas A&M University & President, ACCE Healthcare Technology Foundation

IEC 80001 AND PATIENT SAFETY Stephen L. Grimes, FACCE, FHIMSS, FAIMBE, Vice
President, Technology in Medicine, Inc. & Immediate Past President, American College of Clinical Engineering (ACCE)

PANEL DISCUSSION: HOW WILL MDDS AND IEC 80001 IMPACT THE MARKET?

HOW CLINICIANS AND DEVICE MANUFACTURERS CAN COLLABORATE TO REDUCE RISK Steven R. Rakitin, President, Software Quality Consulting & AAMI member

THE BASIC COSTS OF CONNECTIVITY Bridget Moorman, CCE, President, BMoorman Consulting, LLC

Day 2:

TRACK A - INFRASTRUCTURE

CONVERGED MEDICAL DEVICE AND ENTERPRISE NETWORKS: CHALLENGES AND BEST PRACTICES

OPTIMIZING SUPPORT FOR POINT OF CARE AUTOMATION

DISTRIBUTED ANTENNA SYSTEMS: REALITY VERSUS HYPE

WIRELESS SENSORS: PERFORMANCE, COEXISTENCE & INTEROPERABILITY

TRACK B – CONNECTIVITY SOLUTIONS

INFUSION PUMP CONNECTIVITY FOR EMR DOCUMENTATION

ENABLING POINT OF CARE APPLICATIONS WITH DEVICE CONNECTIVITY

POSITIVE PATIENT ASSOCIATIONS IN CONNECTIVITY

OPERATING ROOM INTEGRATION: THE INFORMATION CROSSROADS IN SURGERY

TRACK C – CLINICAL & WORKFLOW IMPACTS

POST SURGICAL PATIENT-CENTRIC CENTRAL SURVEILLANCE: PREDICTORS OF CARDIORESPIRATORY MORBIDITY

THE LINK BETWEEN MEDICAL DEVICE CONNECTIVITY AND CLINICAL DECISION SUPPORT FOR INTERVENTIONAL GUIDANCE

CREATING A CONNECTIVITY STRATEGY FOR HEALTHCARE

OPTIONAL POST-CONFERENCE WORKSHOPS

ONE -- DISTRIBUTED ANTENNA SYSTEMS IN HOSPITALS: BEST PRACTICES

TWO -- IEC 80001-1: APPLICATION OF RISK MANAGEMENT FOR IT NETWORKS INCORPORATING MEDICAL DEVICES

UPDATE (9/10/09): Tim is posting conference updates here: The Connectologist

UPDATE (9/16/09):

Review #1: Wireless connectivity and medical devices

Integrating wireless technology into medical devices presents the industry with both a carrot and a stick: Stimulus cash (carrot) versus increasing demand for connective devices from hospitals (stick).

Review #2:  Analyst: Healthcare’s wireless sensor opportunity

Gee broke down some of the drivers for the recent interest in medical sensors, outlined use cases and dissected the market for the more than 200 attendees at last week’s event.

Tags:,
Posted in Interoperability, Medical Devices | No Comments »

Liberate the Data!

Friday, April 3rd, 2009

Peter Neupert's post Tear Down the Walls and Liberate the Data is worth reading. There are some Microsoft-centric comments, but a number of the linked articles are good and the overall message is correct (IMO anyway).

I might have tried to find a better analogy than 'tear down this wall', but that's because I was never a Ronald Reagan fan.  Nevertheless, this gets across the primary point:

What’s of paramount importance is liberating the data and making it available for re-use in different contexts.

Two major 'walls' stand in the way of this:

  1. “it’s-my-data”
  2. “waiting-for-the-right-standards-set-by-government”

Both exist because of the perceived competitive advantages they provide to organizations and vendors.

Interoperability of data, or enabling data to become "liquid" would allow it to flow easily from system to system. These challenges are the same ones addressed by Adam Bosworth that I discussed in Dreaming of Flexible, Simple, Sloppy, Tolerant in Healthcare IT.

The technical issues are complicated, but I also believe that they not the primary reason that prevent  health IT systems from inter operating.  As Peter suggests, it would be good for HiTech dollars to be used to break down some of the more difficult barriers that prevent data liquidity.

The "proven model[s] for extracting and transforming data" do exist and there is no excuse not to use them.

After thinking about it some more, a more cautionary analogy may be The Exodus -- Mosses leading the Israelites out of the Land of Egypt ("let my data go!").  1) It took an act of God to part the Red Sea, and 2) after their dramatic escape they roamed the desert for 40 years. Let's hope that health IT interoperability does not need devine intervention or suffer the same fate.

Tags:, ,
Posted in EMR, Interoperability, Microsoft | 2 Comments »

Contradictory Observations and Electronic Medical Records

Tuesday, March 3rd, 2009

Martin Fowler has an interesting discussion in his ContradictoryObservations post.  This little slice of medically related software design insight is particularly relevant because it highlights (at least for me) the complexity of the use of electronic medical records and their interoperability.

In a broader sense I suppose it also shows some of the underlying difficulties that face the Obama administration's new EMR adoption push.  But I'm not going there.

The concepts of observations,  rejection, and evidence are good, but they're just the tip of the iceberg:

rejected and evidence

Even after you've modeled the data interactions, how do you effectively communicate these concepts to the user?  Or to another EMR that doesn't know about your model or how it's used?

Martin's view is that:

Most of the time, of course, we don't use complicated schemes like this. We mostly program in a world that we assume is consistent.

Unfortunately, many of the issues facing electronic medical records do require complex solutions. And even when the world is consistent, how you implement a solution may be (actually, will probably be) very different than how I implement it.  Either way, interoperability will always be a challenge.

We're going to need lots of good software design tools to solve these problems.

Tags:, ,
Posted in EMR, Interoperability, Programming | 4 Comments »

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

Saturday, January 3rd, 2009

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.

Tags:, , ,
Posted in EMR, Google, HL7, Interoperability, PHR, Programming | 2 Comments »

« Older Entries
Newer Entries »