The ARRA (American Recovery and Reinvestment Act) provides incentives for qualifying health care providers that implement health IT systems in the next few years. Among the requirements for receiving the incentive is that the provider can demonstrate the health IT system can “is connected in a manner that provides, in accordance with law and standards applicable to the exchange of information, for the electronic exchange of health information to improve the quality of health care.” There is substantial incentive, therefore, for health providers to implement systems that can effectively exchange data with other systems through a Health Information Exchange (HIE).
ARRA is not the first statute to push the exchange of information in the health care market. In fact, HIPAA, when it was originally implemented in 1996, provided authority for the Secretary of Health and Human Services to establish data exchange guidelines for claims and eligibility data with health insurers. These standard formats, as defined by ANSI, pushed the health industry into an era of electronic data exchange with most health insurers. Of course, what’s on a claim form to the insurance company is not the same as the kind and extent of the data that would be available in a health IT system like an electronic health record (EHR). The clinical data sent to insurers – the patient’s diagnosis – is short hand in comparison to the significant amount of clinical information collected on a patient like lab results, patient histories, or reports from specialists. And consistent storage of this information in EHR’s is in shorter supply in comparison to diagnosis data in their practice management system cousins. Even the patient medication list, which is typically stored as structured data in most health records, may not necessarily be stored in a consistent format across EHRs.
HIE systems today have a substantial uphill battle ahead of them to be able to collect and meaningfully display data across a variety of information systems, so that consumers of this data will be able to use it in a meaningful way. There is substantial pressure on the health market, however, to improve efficiency. Today the U.S. health market struggles with effectively managing the care of patients, partly because of the amount of data available on patients, and the amount that is redundant but inconsistent. For patients with significant health problems, a visit to a variety of medical professionals results in a fair number of disparate documents about the patient with a variety of sometimes conflicting information about the patient. A patient taking 5 or 6 different prescriptions may forget one when asked by one specialist; different physicians may end up ordering redundant tests for the same patient; patients seeking narcotics may be able to play physicians off of each other. HIE systems present a possible solution to the problem of securely sharing information between health care providers that serve the same patient.
Therefore, as incentives and pressures are placed on the market to improve efficiencies, I would anticipate that some of the technical issues with exchanging health information will be resolved. That leaves a number of other areas to be more completely addressed, including patient privacy, the quality of data and the ability to trust the source of the data, and backup and redundancy.
The Privacy Problem
One of the great challenges for the HIE movement is maintaining patient privacy. HIPAA was originally implemented in part to specifically address patient privacy, as have a number of other state laws on this topic (for example, the Maryland Medical Records Act, See Md. Health-Gen. Code Ann. § 4-301 et seq.). And other states are getting in on the action to protect consumer privacy, including Massachusetts, Minnesota, and Nevada, just to name a few.
However, laws alone may not be enough to effectively regulate and protect the availability of health data. In the present HIPAA enforcement regulations (which were modified by ARRA this year), the top fines (where the act in violation of the security regulations was a negligent rather than an intentional one) are relatively low compared to the potential size of an HIE (for example, if a company like google or Microsoft was to become a dominant HIE) because the fines are a flat rate per incident rather than being scaled according to the company’s gross revenue or the severity of the breach or finding. The ARRA did move in the right direction this year by implementing a four-tiered approach to violations from the original enforcement authority under HIPAA, but further scaling may be required for this to become an effective deterrent to lax security practices.
Furthermore, having a patchwork of privacy laws increases the overall cost of compliance for HIEs, which increases the cost to implement these systems without necessarily improving the actual security of the information stored at the HIE. This is caused by overlapping regulation along with the expense of responding to multiple authorities with the right to audit or investigate the HIE (as larger HIEs will undoubtedly operate across state lines). Sadly, I imagine that this problem will probably get worse before it gets better, given the number of relatively autonomous sovereign powers within our country (5o states + the federal government) and the scope and scale of the privacy issue being considered.
I say that because of the amount of data that will likely become available within HIEs across the nation that will eventually be the health data for all 300 million of us. Assuming that the typical patient’s chart is between 5 and 10 megabytes (with images and other pdf attachments that are not as small as document stored within a data table), the total data storage for all citizens would be between 1,500 and 3,000 terabytes – or about the total storage capacity of about 30,000 new Macbooks. For comparison, in 2006, Google’s estimated storage of data for its entire operation was about 850 terabytes for storing information on about 24 billion web pages. It is a lot of data, and a lot to manage. In today’s fractured regulations, there will be substantial governmental interest in further regulating this data in the next few years. However, without more consistent regulations, patient privacy may not be effectively protected.
Changing Attitudes Towards Privacy
Our future privacy policies may also be impacted by the attitude of our youth to privacy today. Social networking sites, for example, allow for the exposure of a lot of information about the youngest among us, but the predominant users of these systems don’t seem to mind very much. Now, of course, facebook is not designed for users to post their most recent blood sugar levels, so who knows whether college kids would treat that information in the same manner that they treat pictures snapped of them by the college paparazzi at the fraternity Friday night bash, but it stands to reason that the next generation’s attitudes towards privacy will be substantially different than the present one that has been called to govern the nation.
The result may be a reduction in the emphasis on privacy with an increasing criminal penalty for those that engage in theft of information. For example, perhaps instead of worrying as much about whether health data is squirreled away in an underground bunker with Dick Cheney, the future leaders of the nation will make this data generally available via the internet, ultimately reducing its value to would-be thieves. For myself, I can’t say it matters much if others know than I have high cholesterol and a family history of diabetes, but I also don’t think there is much stigma attached to either of these conditions as there might have once been (or might still be for other health issues).
Data Quality and Trusted Sources
HIEs will also need to address head on the quality and reliability of data stored in their databases. Today, data systems do not generally go beyond the initial setup of some kind of private network and the file formats that are acceptable for data to be exchanged. Inherently, one system trusts the data it receives from the other and merely re-publishes it into its own database, identifying the source of the data. Usernames and passwords may just not be enough for everyone to know that the data being sent or received is accurate and reliable.
In addition, HIPAA (and some other laws) have placed a small emphasis on technical encryption, and the result is that little has been done with these technologies for most systems today to ensure that data entered is not repudiated later by the person that purportedly entered it. For example, many commercially available database systems are not natively encrypted. Local area network activity on the wire is rarely encrypted, as database systems rely on border security devices to keep outsiders out of LAN activity. Passwords are not consistently complex across an enterprise (especially where multiple database systems maintain their own passwords and accounts), and certainly cannot reasonably be changed frequently enough to ensure the password has not been compromised (without the user community revolting against the IT staff). And users routinely share passwords in spite of the numerous repeated messages from system administrators to not do so.
Furthermore, data exchanged between systems relies on the initial configuration of the networking that connects the two systems to remain uncompromised. There is no further system verification to ensure that messages actually received across these systems are correct in the typical data exchange design. TCP itself was designed with a checksum in each packet, but that only tells the receiver if the packet received matches what was intended to be sent by the source device, not whether the data sent is coming from the human/system source alleged (e.g., the laboratory technician or physician that actually created the entry in the first place).
I anticipate that the future of authentication will be to move towards far more sophisticated and multi-level authentication (even though the biometric movement seems to have lost steam, at least in the general consumer market). For example, instead of or in addition to a username/password, systems may also generally implement a token, or other physical card to grant access (such systems exist and are in general use today for some systems). Other security measures may involve thumbprints or biometrics. I would also imagine that more sophisticated encryption algorithms could be used beyond 128-bit cipher, and that encryption might occur at a more basic level than it does today (if transmissions are encrypted at all). For example, databases themselves may be encrypted at a record or table level, or application access could be managed through an encrypted socket instead of plain text as many operate now.
Beyond user access to put in data, surely there be could some additional layer of verification that could occur once data has been received from a producer system which could be, by design, independently verified before being committed to the receiving system. The alteration (or just erroneous entry) of data in transport from one system to another creates the real possibility of a bad health care decision by professionals using the data. This is certainly one of the major weaknesses of consumer level HIEs such as those from google or Microsoft which must rely on the consumer to enter their own lab and pharmaceutical information into the database when that data is not available electronically, or on data providers that rely on administrative or clerical staff to actually do the data entry without further review before distribution.
HIE Backup and Disaster Recovery
Today, a number of technologies exist that allow for data backup and redundancy to ensure that systems can be highly available and resistant to significant environmental or system disasters. One category of technology that addresses redudancy is called cloud computing, which is a kind of modern equivalent to what application service providers (ASP) of the 1990’s were offering, or what the ancient mainframes of yesteryear offered to computing users back in the bad old days of the 1970’s. What is fundamentally different today, however, is the possibility of having massively redundant and distributed information systems that belong to a cloud, where both ASPs and mainframe computing were often centralized into one server room or series of server rooms in one facility.
A common example of computing in the cloud today is gmail, which is an email service provided by google for free to consumers. There are still, somewhere, servers connected to the internet and controlled by google that will respond to SMTP requests, but google most likely has these servers distributed all over the planet and connected to a larger, redundant network infrastructure. Data stored on these servers are likely real-time replicated so that all gmail replication partners are up to date, regardless of which one you actually connect to when you use your web browser to navigate to your email account. Gmail has been around for some time now, and there are a fair number of users (26 million according to one article as of last September; wikipedia claims there are 146 million gmail users each month as of July 2009).
However, even gmail has outages, in spite of the sophistication of its backup and redundancy. These outages are inconvenient to email users, but could be fatal if relied upon for data in emergency rooms. And local EHRs undoubtedly fail more often than much larger, hosted solutions. Perhaps the incentives in the market for HIEs and EHRs will push us into a new age of reliability in IT, based on cloud computing ‘2.0’.
Future is Fuzzy
While it is not clear what may happen as more data is available, I can say that the amount of money on the table under the ARRA, in state budgets and privately in the hands of organizations like Microsoft and Google is pushing health information exchanges into the forefront of health IT initiatives. More information being available and shared that is accurate and adequately protected is very likely to improve health outcomes and increase the efficient delivery of health care. My hope is that we can solve some of the more nagging technical and privacy concerns in the short term.
Faith At Law LLC 