DPC15_300x250_ads_FINAL
PPC_CIPM_300x250.FINAL-01
PSR15_300x250_ads_FINAL

Editor’s Note: In this pair of articles, experts share perspectives on the questions and challenges surrounding healthcare IT and privacy.

Seeking a difficult balance:  The limits of privacy in the emerging healthcare IT ecology

It’s not always easy to strike the right balance between privacy and other values. In particular, because privacy is all about controlling access to personal information, it tends to be in tension with the value of information availability. This tension can become outright opposition in some cases. This article will discuss two healthcare situations in which that is the case, one at the operational level involving emergency access to information and the other at the policy level involving the shutdown of the HIPAA individual identifier by privacy advocates. The latter, in particular, is a story worth recalling because it may be causing the unintended consequence of increasing risks to personal information in the emerging nationwide health information network.

When discussing information security risks, it is probably easier to speak in terms of confidentiality rather than privacy. The three standard objectives of information security are confidentiality, integrity and availability—the “CIA triad.” Privacy in particular overlaps with confidentiality, as both have to do with control of access to personal information. Privacy can be defined as the legally recognized right of an individual to limit access to personal information, while confidentiality can be defined as a condition in which a party is subject to obligations to control access to information. Confidentiality, therefore, enforces the personal information access limitations that privacy laws and individual choices define.

Availability, on the other hand, is all about providing information where and when it is needed, both complete and accurate. Taken to its extreme, availability would not be constrained by any limitations other than the demands of the user. Availability and confidentiality are therefore in tension and may well come into opposition, and the question then becomes how to resolve the conflict.

Almost all security requirements are risk-based, meaning that some degree of risk is inevitable and must be accepted. Conflicting security objectives can therefore be resolved by balancing the relative tolerance for the risks associated with that objective. For example, it might be appropriate to accept a higher level of confidentiality risk if the harms they are likely to cause are materially less than the harms likely to be caused by availability errors. This can be demonstrated with an example from healthcare treatment operations.

The case for weak passwords in the emergency room

For healthcare purposes—and really, for almost all purposes—individual health and safety are and should generally be ranked the most important harms to avoid and, if material, are certainly more important than reputational or financial harms. This suggests a low tolerance for risks of availability errors for systems used to support real-time diagnosis and treatment: A failure to have necessary information available might cause a mistaken diagnosis and kill someone. A lower risk of availability errors might therefore be appropriately balanced against an increased risk of confidentiality errors, which might result in reputational or financial harm but are not likely to result in death.

The need for this kind of balancing act might be found, for example, in electronic health record (EHR) access in an emergency room, which is typically controlled by password. For most purposes, it is considered a best practice to require the use and of unique, mixed-alphanumeric and symbol passwords that are frequently changed to control access to protected health information, especially the kind of detailed, often sensitive information contained in an EHR. Because such passwords are hard to crack, they tend to reduce the risk of confidentiality errors resulting in unauthorized access.

However, by the same token, strong passwords are also hard to remember. Users who are unable to remember their passwords will be unable to access their EHRs, creating a risk of availability errors. A strong password policy that reduces the risk of confidentiality errors, therefore, also increases the risk of availability errors.

In some clinical settings it might be appropriate to forego strong passwords. For example, in an emergency room setting, clinical information may well be needed on literally a life-or-death emergency basis so that the tolerance for availability errors should be very low. The hospital operating the emergency room might therefore conclude that EHR access in the emergency room should not be controlled by strong passwords.

The balancing of risks would be very different for a claims processing system in the same hospital. Claims information may include highly sensitive personal information but is used for financial purposes and so does not need to be available with the same urgency as clinical information. In this setting, there would be a higher tolerance for availability errors, and a strong password policy might be very appropriate.

Unintended consequences of the demise of the HIPAA patient identifier

This same tension has had some interesting consequences for national health information technology policy. The American healthcare sector has been going through a difficult infrastructure transition for a long time, as paper-based medical record and administrative systems are over time converted to EHRs and management information and claims processing systems. These systems in turn are becoming increasingly interoperable, under policy initiatives pursued by both parties and many private organizations to establish health information exchange (HIE) functions and organizations.

These policy initiatives have brought us such noteworthy developments as the Health Insurance Portability and Accountability Act (HIPAA), known to most of us principally for its privacy and security mandates. In fact, however, these were but a small part of the “Administrative Simplification” section, which in turn were but a small part of HIPAA which was intended to promote and standardize electronic healthcare claims transactions. The privacy and security provisions were almost an afterthought, added on to help reassure the public that the new systems would protect their information against improper use or disclosure.

For the last decade or so, the principal public policy initiative has been development of a seamless nationwide network for HIE among interoperable EHRs. This network—probably ultimately a “network of networks” operated by various organizations—will someday, ideally, allow for on-demand delivery of information from the EHR of any healthcare provider who has treated a given patient to the EHR of any other provider where the patient needs care. For example, if I had a medical emergency in New York, my hospital would pull in information from my primary care doctor’s EHR in Seattle; the EHRs of specialists I had seen in San Francisco and Denver, and the EHR of a hospital in Los Angeles where I’d received care. This information could be crucial to my diagnosis and treatment, and my doctors and I would very much want the information to be available. A nationwide HIE, therefore, should have a low tolerance for availability errors.

There are several basic problems with making information available across a network of this kind, but one of the most fundamental is, how does a provider find information? How do you identify me uniquely, so that you can find information about me?

One possible solution was actually provided for in HIPAA, which required regulations establishing a unique patient identifier for use in claims transactions. While not intended to enable HIE, this kind of identifier could play a useful role in the projected nationwide system.

But this potential solution was stopped dead by privacy advocates. Shortly after initial hearings were held on the proposed identifier in 1998, a coalition of privacy advocates objected that this was the first step to a national registry of citizens. There was a public uproar; Congress quickly passed legislation defunding work on the regulation, and no one has been willing to touch it since. Policy concerns about potential privacy violations thus eliminated a potential solution for reduction of HIE availability errors.

And an unanticipated consequence may well be a system which creates even greater privacy risks. In the absence of a universal identifier, the solution to identifying individuals for HIE is the master patient index (MPI). Names—and even names along with one or two other bits of personal information—aren’t very reliable identifiers across a large population. An MPI serving HIE for a large population therefore needs additional demographic information, which must be updated and maintained. Individuals are then identified by a more-or-less formal comparison of demographic data sets.

An MPI is complex enough within a closed network, and complexity only increases with MPIs serving more than one network. A genuinely functional nationwide network will have to have some sort of MPI interoperability solution, which will require even more storage and sharing of information. But the same demographic data that resolves identities is useful for identity theft, so that these new databases and transactions are likely targets for malicious action—a seriously increased risk of harmful confidentiality errors. This may or may not turn out to be a worthwhile tradeoff against the loss of the HIPAA unique patient identifier

Conclusion

There is no single right privacy choice for all situations. Rather, privacy is one of a number of important values which must be balanced, but might not always be fully reconciled, in pursuing personal, organizational and policy objectives. When that occurs, all that can really be done is a careful analysis of the implications of the difficult choices, and a decision that some kinds of privacy risks might be worth accepting to avoid other, more harmful types of risk.

Written By

John Christiansen

0 Comments

If you want to comment on this post, you need to login

Related