Take a look at the major health care IT vendors. They're all working feverishly to collect, collate, process, and puree your health care information, billing codes, insurance carriers, hospitals, quality assurance mandates and red flags, etc.
The prize?
To become our national health care IT system. To own it ALL!
Now look at the pacemaker industry in the US.
Three big companies. All promoting their pacemakers.
Each manufacturer's pacemaker computer is unique to their pacemaker models, but does the same job: they each "talk" to their respective pacemakers and tells them how fast or slow to go and how much energy to use to do the job safely. To do this, they use "protocols." Protocols are closely-guarded trade secrets.
And so as a fellow, when we did not know which manufacturer's pacemaker was installed in a patient's chest, I could not bring a single computer to talk to the pacemaker inside a particular patient. Instead, I had to push a huge cart carrying multiple computer programmers to the patient's bedside, each with their own special printer paper and programming heads, to interrogate the patient's pacemaker at their bedside.
Recall that the first pacemaker was developed in 1949. Since that time, the basic design and construct of pacemakers has become fairly standardized. Sixty years have passed. Today, do any of these pacemaker companies' computer systems talk to their competitors' pacemakers?
Of course not.
Share protocols? Are you crazy? That would compromise their intellectual property!
You see, it's really not about what's good for the patient or doctor.
It's about the money.
'nuf said.
-Wes
7 comments:
We're actually running into the same issues with regard to transmitting 12 lead ECGs from the field to the emergency department.
If your hospital has multiple EMS systems that deliver patients to your ED, and each EMS system uses a different monitor/defibrillator (Physio-Control, Philips, or ZOLL), then you need three different "STEMI solutions" to make it work.
You see, it's not enough for a company to figure out an inexpensive way to let you transmit a diagnostic quality ECG to the hospital. You need a "STEMI solution" that manages your data and requires a monthly subscription!
You didn't realize that you needed these things, but don't worry! Industry is here to educate you.
Yep..I am in the technology industy and just like M$oft vs. Java, eveything is: "I will take my ball and go home!"
Pretty sad...
Have you tried using a Universal remote ($ 9.99 at Target)?
Marco
Wes,
You sure have hit this one on the mark. We value competition as a driver of inovation, but when you have all these competing companies running on different platforms with their own proprietary software, you lose the advatages of an inclusive EMR that contains all the patients medical information. Writing bridges from one to the other is somthing that seems to require exorbitant cost since it is not something the software company wants to encourageand only they can do it sinc they own the code.
This is an area that needs a goverment solution, which is to provide the data retention facilities that will house this medical information which can then be deposited from several sources. It is ludicrous to expect private companies to be the repositories of this sensitive information (google or microsoft).
Healthcare organizations are just as bad; once they have an EMR, they try to leverage it so that only tests ordered through their facilities are easily stored in the EMR, effectively creating barriers to competition. All are examples of why the free enterprise system is not such a great idea when it comes to health care (or apparantly the financial services industry for that matter).
Don't forget about CCHIT - the organization making standards so that they can integrate. This was mandated by the government, and its director, Mark Levitt, equates what he is doing with WiFi standards. WiFi transmitters and receivers are made by different manufacturers, but they interconnect.
Rob-
But rest assured we have privacy laws that will find WiFi has "inadequate security." This was the case already with Bluetooth in medical applications: it was just not secure enough and its tranmission speeds were too slow.
The other problem for companies has been the mountains of regulatory hurdles (with their associated expenses) that must be conquered to implement a new computer in medical applications: the FDA, the FCC, liability issues, etc. (If there's a problem, who's fault was it?). It's usually just not worth the hassle for them, so we sit with the old proprietary systems for years on end...
You would think that there would be a basic set of polling commands based on a agreed upon standard that just says - hello device, can you identify yourself? i know folks have mentioned wifi and that is a basic function of a wifi device - declaration and communication of device type.
maybe this basic device ID is for use under the "breakglass" scenario.
I am in the integration business as product manage for Cloverleaf (an interface engine). I've been at it for 13 years. It never amazes me to hear of vendors doing all they can to NOT make it easy to share data. It is done mostly so they can build proprietary interfaces for a high prices for their customers desparate enough to pay it.
I know these vendors want to keep their proprietary "secret sauce" secret, but when a patient's life is on the line, it is the right thing to do.
We can hope HITSP can get to this use case and recommend an interoperability. I know HL7 has a device interoperability group and I am sure there are other groups talking about these things. Any one know if a standard is being worked on?
Post a Comment