Thank you so much for bringing some clarity to this discussion. I made it a point to visit all blockchain vendors at HIMSS 2017 and there was not a single answer for 10 MB CCD, let alone imaging data.
On top of that, HIEs solve many of the "sharing" use cases today. The challenges in healthcare data sharing are semantic interoperability. Trust is tertiary and easily solved using existing standards.
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.
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.
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.
For one, the creation of a single standard document for representing a medical history would go a long way towards enabling applications across the medical spectrum to coexist.
This document type does exist. Please review the emerging HL7 v3 documentation. Pay particular attention to CDA/CCD.
The bottom line is that once there is convergence around interoperability, which proprietary EMR solution a Healthcare Organization utilizes matter much less less. Prior to CCHIT and changes in STARK, vendors had little incentive to develop interoperable solutions - vendor lock-in is part of the HIT business model.
For once, the government is actually driving positive change into an industry. Through provider-based incentives (carrot vs. the stick), HCOs (Healthcare Organizations) will have positive incentive to implement interoperable solutions.
It's a facinating time in HIT, and I'm frankly enjoying being on the vendor side of right. I expect fundamental change over the next 5-7 years in HIT, unlike anything we've seen in the last 15. Great stuff, really.
Google isn't actually behind Microsoft, as Microsoft's implementation of healthvault is actually somewhat questionable. It's as if the company paid no attention to existing standards, and decided to implement a PHR system however they damn well pleased. CDA or CCD support? What's that? IHE standards?
If anything, Microsoft is ahead in the game of press releases, but certainly not in a functioning and useful Electronic Health Records system.
Keep in mind that ultimately, suppliers NEVER bear the burden of sales taxes, or any cost, for that matter - all costs are paid, one way or another, by the consumer.
This is true in the general case, where a sale is actually made. However, where the demand curve is shifted through the price change caused by additional tax burden, sales are lost. Thus, while a consumer bears the cost of taxes in an actual sale, a business bears a cost in lost sales.
Simple economics.
Anyway, the book is called: Concurrent Programming in Java, Second Edition, Doug Lea (Addison-Wesley)
Good book, by the way. I'm actually a.NET guy, and don't do that much Java, and I consider this book my go-to reference for understanding many threading issues. While there are sometime subtle differences between the two threading models, I consider Doug Lea's text a "must-read," even for people on the.NET side of the house.
For everything I have worked on, it has been less than or equal to 2.
Agreed. I'm currently a software dev manager, and that's one of the questions I continue to ask myself:
Who are the essential people on my team?
Interestingly enough, as a manager, my name is never on that list, though it was when I was a developer. What is noteworthy, is that this number is always very, very low, regardless of the size of the project.
IronPython is integrated into VS.NET 2005. In fact, the Visual Studio 2005 SDK (VSIP) uses the IronPython IDE integration as the reference implementation for Visual Studio integration.
Visual Studio 6.0 comes with an MSDN subscription, so yes, you could have purchased this software. However, it would have cost quite a bit more than VS.NET C++ Standard Edition (2003).
I certainly wouldn't use a source control tool that hasn't even been released yet.
And VSS 6.0d is hardly eight years old - it was released in 2003, making that release only two years old.
I really, really dislike VSS, and while the 2005 version is somewhat better, it is still missing the compelling feature set of many of its competitors. The only reason that VSS even has an install base is because it is included with MSDN.
My apologies - you were correct in your original statement. Although I did read the entire post, I'm afraid that I focused on your original, slightly misleading statement of "Java has multiple inheritance."
While this is true, and you go on to properly explain how Java supports MI, I'd like to point out that the lack of implementation inheritance in both Java and.NET (C#/VB.NET/C++/CLI) is a sore point for many programmers.
These languages only have partial MI support, and in my opinion, this slightly weakens both technologies.
Multiple inheritance. Java has multiple inheritance...
Um, no, java does not fully support multiple inheritance. Multiple class inheritance is explicitly NOT supported. You may achieve many the same results through the use of interfaces, but Java does not support multiple implementation inheritance.
And in reality most compilers are written in lex/yacc/bison/etc. and then tweaked to generate the appropriate machine instructions from the parsing code.
While this may be true for open-source and academic languages, I've yet to see evidence that these tools are used often in commercial compilers.
Slashdot Mirror
And that's why HIEs exist. The problem is solved, no magic bullet required.
As an aside, HIEs also provide interesting analytics solutions that blockchain cannot.
Thank you so much for bringing some clarity to this discussion. I made it a point to visit all blockchain vendors at HIMSS 2017 and there was not a single answer for 10 MB CCD, let alone imaging data.
On top of that, HIEs solve many of the "sharing" use cases today. The challenges in healthcare data sharing are semantic interoperability. Trust is tertiary and easily solved using existing standards.
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:
http://www.imdb.com/title/tt2024432/?ref_=sr_1
-jd
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.
-jd
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.
-jd
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.
-jd
For one, the creation of a single standard document for representing a medical history would go a long way towards enabling applications across the medical spectrum to coexist.
This document type does exist. Please review the emerging HL7 v3 documentation. Pay particular attention to CDA/CCD.
The bottom line is that once there is convergence around interoperability, which proprietary EMR solution a Healthcare Organization utilizes matter much less less. Prior to CCHIT and changes in STARK, vendors had little incentive to develop interoperable solutions - vendor lock-in is part of the HIT business model.
For once, the government is actually driving positive change into an industry. Through provider-based incentives (carrot vs. the stick), HCOs (Healthcare Organizations) will have positive incentive to implement interoperable solutions.
It's a facinating time in HIT, and I'm frankly enjoying being on the vendor side of right. I expect fundamental change over the next 5-7 years in HIT, unlike anything we've seen in the last 15. Great stuff, really.
-jd
Google isn't actually behind Microsoft, as Microsoft's implementation of healthvault is actually somewhat questionable. It's as if the company paid no attention to existing standards, and decided to implement a PHR system however they damn well pleased. CDA or CCD support? What's that? IHE standards?
If anything, Microsoft is ahead in the game of press releases, but certainly not in a functioning and useful Electronic Health Records system.
Well spoken, sir.
Keep in mind that ultimately, suppliers NEVER bear the burden of sales taxes, or any cost, for that matter - all costs are paid, one way or another, by the consumer.
This is true in the general case, where a sale is actually made. However, where the demand curve is shifted through the price change caused by additional tax burden, sales are lost. Thus, while a consumer bears the cost of taxes in an actual sale, a business bears a cost in lost sales. Simple economics.Good book, by the way. I'm actually a
For everything I have worked on, it has been less than or equal to 2.
Agreed. I'm currently a software dev manager, and that's one of the questions I continue to ask myself:
Who are the essential people on my team?
Interestingly enough, as a manager, my name is never on that list, though it was when I was a developer. What is noteworthy, is that this number is always very, very low, regardless of the size of the project.
IronPython is integrated into VS.NET 2005. In fact, the Visual Studio 2005 SDK (VSIP) uses the IronPython IDE integration as the reference implementation for Visual Studio integration.
Perhaps - but it is fiendishly difficult to short scox stock, so it's not all upside here.
Something to watch out for with C# and .NET is that there isn't any native .NET access to the serial port
There is serial port access in C#/.NET 2.0.
Visual Studio 6.0 comes with an MSDN subscription, so yes, you could have purchased this software. However, it would have cost quite a bit more than VS.NET C++ Standard Edition (2003).
I certainly wouldn't use a source control tool that hasn't even been released yet.
And VSS 6.0d is hardly eight years old - it was released in 2003, making that release only two years old.
I really, really dislike VSS, and while the 2005 version is somewhat better, it is still missing the compelling feature set of many of its competitors. The only reason that VSS even has an install base is because it is included with MSDN.
My apologies - you were correct in your original statement.
.NET (C#/VB.NET/C++/CLI) is a sore point for many programmers.
Although I did read the entire post, I'm afraid that I focused on your original, slightly misleading statement of "Java has multiple inheritance."
While this is true, and you go on to properly explain how Java supports MI, I'd like to point out that the lack of implementation inheritance in both Java and
These languages only have partial MI support, and in my opinion, this slightly weakens both technologies.
Multiple inheritance. Java has multiple inheritance...
Um, no, java does not fully support multiple inheritance. Multiple class inheritance is explicitly NOT supported. You may achieve many the same results through the use of interfaces, but Java does not support multiple implementation inheritance.
And in reality most compilers are written in lex/yacc/bison/etc. and then tweaked to generate the appropriate machine instructions from the parsing code.
While this may be true for open-source and academic languages, I've yet to see evidence that these tools are used often in commercial compilers.