I fundamentally agree with the point that putting stimulus money into building a bad system will leave us locked into a bad system, but there are some often-repeated claims about electronic medical records that are disconnected from technical reality. One of these is the ATM example - that health data should flow as easily as ATM data.
Why an ATM is completely different from an EMR
1. ATM Data is much simpler than health data.
ATM data is simple. Account number. Bank (routing) number. Balance. Withdrawal amount. Timestamp.
Health data is complex. Text. Images. Video. Blood pressure. Temperature. Hundreds of blood chemistry values. And more.
To simply wave your hands and say that if we can figure out how to transfer your bank balance information, we can figure out how to transfer images and video and blood pressure is to gloss over one of the fundamental problems: truly standardizing all this is not simple. Every other standard I've been involved with (the TIFF image format, the PDF format, and more) has gone through a difficult growth cycle where everyone found out that implementations of standards are not so standard. (But see my previous post for more on that.)
2. Money is fungible; health data is not.
If someone skims your ATM card info and empties your account, this can be fixed. The bank puts the money back into your account, and you are made whole. You'll want to change your account info to stop the thief from future escapades, but the dollars that are put back into your account are just as good as the dollars that were stolen.
If someone steals your health data, we can't just "put it back". The horse is out of the barn. I've had my credit card data exposed by a newspaper glitch. It was easy to fix, and I don't hesitate to use my new credit card. It would take only one publicized event of health data loss (and we've already seen providers caught peeking at celebrity files) for me to seriously ponder what I tell my doctor, which leads to a point worthy of its own headline:
Health data is more private than any other transaction
If there isn't something in your medical record that you wouldn't want the world to know, then count yourself lucky. Electronic medical records used to be sold as better than paper because access could be audited electronically but not with paper. Then came data interchange, and the multiplying possibilities for improper access might start to outweigh the deterrent value of auditing.
I'm not saying that these problems cannot be addressed, but to think that they will be anywhere near as easy as setting up an ATM network vastly misses the fundamental nature of multiple implementations of standards and the complex, private nature of medical data.
Saturday, March 28, 2009
Friday, March 27, 2009
Web standards are NOT a good guide for electronic medical record standards
Summary
Web standards are often held up as a model of standardization for medical records to follow, yet a closer examination of web standards quickly reveals many areas where standardization badly falls short. The implementations of HTML in web browsers are not well standardized despite serious attempts to define standards and a limited number of browsers, leading web developers to write different versions of a web page for different browsers. Some things that do seem standard such as the display of Flash content are not standard because Flash is defined as a standard; the display of Flash content is standard because Adobe Flash Player (and only Adobe Flash Player) is used as a browser plug-in to play the Flash content regardless of which browser is being used. Finally, a quick survey of the history of PDF and the current state of PDF shows that even with one company creating both a very public standard and also the de facto implementation of that standard, interoperability problems abounded. Web standards, when properly understood, should be seen as much as a cautionary tale of what to watch out for as much as they are seen as an example of what to strive for.
HTML
HTML, or Hyper Text Markup Language, is the basic language of a web page. In theory, every web browser would understand the HTML semantics the same way, with differences in display driven only by user context. Same semantics means that every browser would agree that these three words are intended to be bold. Different user context means, for example, that visual browsers will display the words as bold text, while an audio browser would speak those words with more emphasis.
The reality is a lack of semantic agreement. Internet Explorer sets a de facto standard due to market dominance. Other browsers such as Mozilla Firefox follow a shared, published standard, but even among this group the implementations of the standard are not identical. Web developers routinely write two sets of code, one set to fit Internet Explorer and one set to fit the other browsers . That latter set sometimes requires further branching to account for differences among browsers that supposedly follow the same standard. Writing two or more versions of the same code to account for the semantic differences in browsers should give pause to anyone who imagines the World Wide Web a beacon on the hill for electronic medical records.
Browser plug-ins
Much of the seeming interoperability of the internet is due to browser plug-ins. Internet browsers are designed to work with third-party software known as browser plug-ins. These “plug-in” to the browser and add functionality that is not inherent to the browser. One of the more popular examples is Adobe Flash Player. When a web browser displays a page with Flash content, the content is rendered by the Adobe Flash Player plug-in, usually without the user event realizing that this is happening. The reason that Flash content can be displayed the same way in multiple brands of browsers is not due to Flash itself being perfectly standardized. It is due to the fact that Adobe has adapted the Adobe Flash Player to plug-in to each browser, so all Flash content is being displayed by one program, and one program only: Adobe Flash Player.
PDF
From the beginning, Adobe Systems openly published the PDF standard. While Adobe Acrobat was the market leader in creating PDF files, other tools emerged that were able to use the same standard. Despite following the same standard, many of these programs were not interoperable. PDF files created from one program could not always be processed in another program. Vendors blamed each other, and users were often left with unresolved problems. In this case, Adobe provided not only the standard but also the de facto standard implementation of that standard, Adobe Acrobat. Applications that were not compatible with Adobe Acrobat quickly fell into compliance, even in areas where the written standard did not require it. Programs that could each intercommunicate with Adobe Acrobat but not with each other created difficult problems that took much time to resolve over the life cycle of PDF, leaving customers with serious interoperability problems. For those who use non-Adobe PDF solutions, some of these problems persist today.
Conclusion
With only three browsers holding over 97% of the market as of February 2009 , web standards are still not so standard. Most web developers write at least two versions of parts of their code to deal with the lack of real standardization, while quiet monopolies such as Adobe Flash Player substitute for real standardization. When we consider that there are 200 EMR vendors, scaling up the problems that exist in the supposedly standard web should make the story of web standards serve as a cautionary tale of what to watch out for as much as serve as an example of what to strive for.
To Be Clear
I completely agree with those who hesitate to use Federal stimulus money to rush toward cementing one electronic medical record standard. Where we might disagree is that I see the non-standard web standards as an example of exactly what we all want to avoid, not an example of what we will get if we do things right.
Web standards are often held up as a model of standardization for medical records to follow, yet a closer examination of web standards quickly reveals many areas where standardization badly falls short. The implementations of HTML in web browsers are not well standardized despite serious attempts to define standards and a limited number of browsers, leading web developers to write different versions of a web page for different browsers. Some things that do seem standard such as the display of Flash content are not standard because Flash is defined as a standard; the display of Flash content is standard because Adobe Flash Player (and only Adobe Flash Player) is used as a browser plug-in to play the Flash content regardless of which browser is being used. Finally, a quick survey of the history of PDF and the current state of PDF shows that even with one company creating both a very public standard and also the de facto implementation of that standard, interoperability problems abounded. Web standards, when properly understood, should be seen as much as a cautionary tale of what to watch out for as much as they are seen as an example of what to strive for.
HTML
HTML, or Hyper Text Markup Language, is the basic language of a web page. In theory, every web browser would understand the HTML semantics the same way, with differences in display driven only by user context. Same semantics means that every browser would agree that these three words are intended to be bold. Different user context means, for example, that visual browsers will display the words as bold text, while an audio browser would speak those words with more emphasis.
The reality is a lack of semantic agreement. Internet Explorer sets a de facto standard due to market dominance. Other browsers such as Mozilla Firefox follow a shared, published standard, but even among this group the implementations of the standard are not identical. Web developers routinely write two sets of code, one set to fit Internet Explorer and one set to fit the other browsers . That latter set sometimes requires further branching to account for differences among browsers that supposedly follow the same standard. Writing two or more versions of the same code to account for the semantic differences in browsers should give pause to anyone who imagines the World Wide Web a beacon on the hill for electronic medical records.
Browser plug-ins
Much of the seeming interoperability of the internet is due to browser plug-ins. Internet browsers are designed to work with third-party software known as browser plug-ins. These “plug-in” to the browser and add functionality that is not inherent to the browser. One of the more popular examples is Adobe Flash Player. When a web browser displays a page with Flash content, the content is rendered by the Adobe Flash Player plug-in, usually without the user event realizing that this is happening. The reason that Flash content can be displayed the same way in multiple brands of browsers is not due to Flash itself being perfectly standardized. It is due to the fact that Adobe has adapted the Adobe Flash Player to plug-in to each browser, so all Flash content is being displayed by one program, and one program only: Adobe Flash Player.
From the beginning, Adobe Systems openly published the PDF standard. While Adobe Acrobat was the market leader in creating PDF files, other tools emerged that were able to use the same standard. Despite following the same standard, many of these programs were not interoperable. PDF files created from one program could not always be processed in another program. Vendors blamed each other, and users were often left with unresolved problems. In this case, Adobe provided not only the standard but also the de facto standard implementation of that standard, Adobe Acrobat. Applications that were not compatible with Adobe Acrobat quickly fell into compliance, even in areas where the written standard did not require it. Programs that could each intercommunicate with Adobe Acrobat but not with each other created difficult problems that took much time to resolve over the life cycle of PDF, leaving customers with serious interoperability problems. For those who use non-Adobe PDF solutions, some of these problems persist today.
Conclusion
With only three browsers holding over 97% of the market as of February 2009 , web standards are still not so standard. Most web developers write at least two versions of parts of their code to deal with the lack of real standardization, while quiet monopolies such as Adobe Flash Player substitute for real standardization. When we consider that there are 200 EMR vendors, scaling up the problems that exist in the supposedly standard web should make the story of web standards serve as a cautionary tale of what to watch out for as much as serve as an example of what to strive for.
To Be Clear
I completely agree with those who hesitate to use Federal stimulus money to rush toward cementing one electronic medical record standard. Where we might disagree is that I see the non-standard web standards as an example of exactly what we all want to avoid, not an example of what we will get if we do things right.
Subscribe to:
Posts (Atom)