Fortunately, that strategy does not work for HIPAA protected health information. Any identifying number or information fragment that allows you to connect back to the original patient is not allowed. In small communities, this can be as little as age, diagnosis, and zip code.
I expect some interesting court cases over this.
This is the perfect use of government money: projects which are promising (though they may not pan out in the end), which will help many people, and which will not be subsidized by industry because they will not make money in the next three quarters. I don't expect any real results from this study for many years, but I think it's a very important study to do.
While I agree with your premise that this is the perfect example of why we would want government to fund specific types of R & D, I'd argue that private industry is terribly interested in analytics and the ability to provide enhanced clinical decision support and measure previously unknown positive outcomes based on specific treatment protocols or inputs.
HIT companies have saturated the existing EHR market - competitive advantage will come from the ability to derive value from existing data.
Absolutely true! In addition, that needs to be a "fuzzy" five minutes, plus or minus a non-determinate amount of time to prevent further gaming of the system.
The solution is simple. The will to implement it is not there - too much money and special interest in HFT.
I believe that Jason Bateman was in a recent documentary on this topic - seemed very factual, and you should probably consider his plan of action:
DEA does now allow for eRx of controlled substances, but most of the vendor community has not yet caught up to the new regulations.
Has anyone ever anywhere suggested a line item opt out?
Yes - Canada has the Personal Health Information Protection Act (PHIPA) which has what is referred to as the concept of "Lock box." The idea is that you may direct a healthcare provider to not disclose certain data about you. When sharing data, the provider is allowed to disclose that there is additional "lock box" data.
That's great for a data/transmission standard, but another big problem is proprietary databases. Every application has it's own "under-the-hood" storage structure. Imagine if there was a standardized database structure, don't you think that would go a long way towards better interoperability and communication?
No, I don't think a common data storage schema would promote better interoperability. I think a correct data exchange standard will promote this, and vendors will implement data storage and business logic independently.
The problem is that HL7 v 2.x is too "loose" of a standard. It's not particularly descriptive, and both vendors and healthcare organizations have had to stretch the HL7 protocol in order to make it useful.
HL7 3.0 and the RIM have gone a long way towards fixing many of the problems with 2.x. However, 3.0 is not ratified, and there is not straightforward mapping between 2.x and 3.0. This makes it a challenge for vendors and healthcare organizations to leverage 3.0.
HIT is a conservative, slow moving vertical. We'll see gradual movement towards better interop on the wire, and we'll go from there. The RDBMS (or, in some cases OODBMS) is not the place to tackle this issue.
You're only half right. The problem is that HIT vendors are generally well behind the times, slow to innovate and closed and proprietary as all get out. You think MS is bad? You haven't seen highyway robbery until you've seen the shit in a box most HIT vendors push.
While there is certainly long history behind this statement (and some truth), it's not so black and white. Innovation works great when you are landing new client deals - flashy and shiny sells.
However, many clinicians (and dare I say physicians in particular) while normally highly intelligent, are actually very "challenged" users of technology. Changes that are straightforward in the business world are a complete no-go in HIT. Many large healthcare entities will actually draw into contractual language the amount of technical and GUI changes that may occur in a software release or update.
For the most part, it is not vendor resistance to change, but an entire vertical that is very conservative. If it was otherwise, conservative vendors would die very quickly in a Darwinian manner as more responsive companies stepped up to bat.
In short, it's a symbiotic client/vendor relationship that inhibits change.
I've seen PHR to EMR interoperability, but very little EMR to EMR. The Social Security Administration is also doing an enormous amount of work to leverage the NHIN to pass CDA content for disability eligibility, but that's a payor/eligibility type relationship, kinda sorta.
RHIOs were supposed to be the "grass roots" mechanism to get this going, but while there have been some marginally successful RHIOs, most of them are funded by grant money. Without a mechanism to monetize this data exchange, there's little incentive (and action) in EMR to EMR interop.
Again, CCHIT and changes to STARK will inject incentives into adoption of this technology, and you'll see a lot of gears turning in this space.
Those who can't write, write manuals.