My name is Tom Grove, and I am a Management Consultant with Superior Consultant Company of Southfield Michigan, where I work with our HIPAA Planning and Strategy Practice. You may be wondering what a consultant is doing here, speaking on a vendor panel. One of the focuses of our HIPAA practice and, indeed, of our entire company is assisting e-commerce vendors in the healthcare space. Over the past year, we have had occasion to work with dozens of these small vendors as well as some of our traditional friends, the major HIS vendors. It is the perspective of those vendors that I have come to share.
Two years ago, some of my colleagues and I were brainstorming about the Internet and its role in the healthcare industry. At the time, very few hospitals even had web sites, let alone participated in any serious e-commerce ventures. If you think that the need wasn’t there, you would be wrong. The need was there, just as it is today.
Three major obstacles were preventing mass adoption of the Internet as a central part of a healthcare business strategy:
HIPAA provides solutions to all three of those major obstacles. By addressing security and privacy concerns and by providing standards for transmitting critical patient data, HIPAA has unlocked the gates — and Internet solutions to long-standing healthcare problems have come flooding in – creating a whole new market sector, with new HIPAA concerns.
The e-health market has exploded in the last year. A recent report from PriceWaterhouseCoopers put the number of healthcare services companies that received funding in the last two years at over 500. Some additional research at the beginning of this year found another 150 companies just entering or about to enter this sector of the market. Although many of the major market players in healthcare right now are consumer or supply chain oriented and may not be very involved with the kinds of operations that carry HIPAA related materials, that trend is changing. A significant number of new companies are taking advantage of the application service provider (ASP) model and will be providing clinical applications to hospitals. This is a trend that is especially valuable to the smaller hospital, which may soon be able to have a full suite of health information systems, without needing a full suite of computing hardware and full complement of programmers to support it.
Another major segment of the market comprises companies focusing on the healthcare industry as a target for security services, again a direct result of HIPAA. The number of vendors now offering specialized security applications to hospitals as a way for them to become HIPAA compliant is expanding at an astounding rate. Many of these applications combine some form of web-enabling technology with a full suite of audit and authentication tools. A number of new companies have started offering public key infrastructure (PKI) related tools and services focused directly at the healthcare market. My own company, Superior, has recently formed ComTrust(TM) to offer PKI and risk management tools and services specifically to the healthcare industry.
All of this is very exciting, but as my colleagues and I work with these new firms and more traditional firms, on getting their products tuned and ready to be HIPAA complaint products, some significant issues arise.
Currently, there is much confusion about how to implement the security measures. Much of this confusion stems from the lack of technical specificity in security regulations. We certainly understand that this lack of specificity is deliberate and we understand that it was done that way to avoid locking the broad spectrum of implementers into a single model. Many of the newer vendors do not appreciate the reasons, however, and most of them don’t really understand how to make the decisions they need to make, based on an extensive risk analysis.
I can see two options that might relieve some of the confusion. One is for HHS to act like the IRS – to issue non-punitive rulings on various situations posed by implementers. Another more practical approach is for HHS to publish more examples of working solutions with the final regulations, or as a separate clarification to them. The current examples, mostly targeted to small providers, were very helpful.
One related cause of the confusion is some outright misinformation that is circulating among the vendor community. One vendor called to tell us that he recently learned he would be expected to keep all his servers locked inside a vault in order to meet the physical security demands of HIPAA. What is the root of the misinformation? In many cases, the mere volume of the regulations with the associated commentary discourages individuals from reading the complete text. In addition, some vendors (with whom we have spoken) aren’t fully conversant with the regulations because they sometimes find the regulations difficult to understand, and because they are trying to interpret the regulations without a clear understanding of the intent.
I would encourage HHS to be very forthright about the intent of regulations, and the reasoning behind the choices — and to publish the intent as clearly as possible. If the regulations themselves are not the place for this clarification, then perhaps it could be released as a supplementary document.
Next, the regulations define data authentication as “the corroboration that data has not been altered or destroyed in an unauthorized manner.” The regulations go on to give examples of how data corroboration may be ensured including the use of a checksum, double keying, a message authentication code, or a digital signature. Some questions have arisen over what will be sufficient to meet this requirement, particularly since the standard seems to apply to both transmitted and stored data. An audit trail, not mentioned in the examples, provides critical information about who might have altered stored data. At the same time, a checksum, which is mentioned, does little to prove that stored data was not modified in an unauthorized manner, so long as the alterer uses the authorized application that will update the checksum at the time of the data change. More clarity on how this regulation applies to transmitted vs. stored data would be of great benefit.
One area of particular interest to many of our clients, particularly those developing browser-based products, is open networks and encryption standards. There have been many questions raised about what qualifies as an open network and even more questions about how to go about providing the answers. My colleagues and I are certain that what constitutes acceptable protection will change over time, as computers get faster and current encryption standards become more vulnerable. I know that some separate guidelines have been published by HCFA defining what constitutes acceptable encryption for them. Our clients are clamoring for more clarification, and more examples of what will be required.
One major HIS vendor tells me that because the company has a single product line, the implementation calendar does not represent a problem. For many others, however, the issues are less clear. Causing some concern among my vendor contacts are issues such as the mechanics of implementing various parts of the transaction standards, and in what order—so much concern, that WEDI has formed a working group to address this issue and produce a Strategic National Implementation Plan, which views the implementation of HIPAA requirements as nothing less than a fundamental restructuring of the business of healthcare information technology. The underlying belief is that two years isn’t a lot of time to do something as big as that. Coordination is the name of the game.
Other vendors, however, have suggested that the rules be amended to call for compliance on all parts of the regulations on one specific date. I realize that this may be beyond what this committee can recommend, but I ask you to keep this in mind, particularly if implementation deadline delays are ever discussed.
One thing that my vendor colleagues all agree on — customers are calling, asking about compliant versions of software. The continuing delays in publication of the final regulations are frustrating to them. While we appreciate the volume of work to be done, and understand that a rough timetable has been proposed, we encourage you to support rapid publication of the remaining rules.
There is absolute confusion about business partner agreements, as required by the privacy standards and chain-of-trust agreements, as required by the security standards. The security standards say very little about what these agreements entail, except that the intent is that the “same level of security” will be maintained as data is transmitted and re-transmitted among business partners. They don’t even define business partner. In contrast, the privacy standards say quite a lot about the restrictions that are in force and who is responsible for meeting them. My lawyer friends tell me that in legal terms, when something is described in two different ways in regulations, it’s because it means two different things. If there is a distinction between what the two agreements require, it’s unclear. If there is no distinction, that’s unclear too.
Part of the lack of clarity here undoubtedly relates to the limitations of the law on who the HIPAA standards can apply to. The rest probably stems from the recommendations coming from different sources at different times. In any case, we urge two resolutions to this issue.
A final privacy question I get repeatedly from start-up Internet vendors concerns de-identified information. There is much concern about how to go about de-identifying data, since it is getting easier to re-identify data, particularly involving patients with uncommon conditions. Similarly, some of the de-identification discussed in the regulations may destroy the usability of the data. The reason for all these questions, of course, relates to potential commercial value of the resulting data sets, an area that, in itself, raises some interesting questions. I urge the committee to recommend clarification of the de-identification of data and the allowable uses of the resultant data set.
In closing, I would like to thank the committee, both for inviting me here today and for their leadership in driving the HIPAA process. I sincerely hope that the information my fellow panel members and I provide today is of great assistance in shaping the direction of great things to come.