Fragments of Health Policy

Tuesday's New York Times ran an article (subscription req'd) on people who are denied access to health-related info (for themselves or family members) due to medical personnel not knowing how to interpret HIPAA regulations. HIPAA is one of the key pieces of US legislation governing privacy of medical information. Medical personnel apparently deny access in many cases that HIPAA would allow because the boundaries of the law are either unclear or unknown to the personnel.

Given the liability involved, denying access is an obvious default. Denying access beyond the intent of the policy becomes problematic, however, when it prevents people from getting information they need in order to get something legitimate done. The balance between protection and availability is hard to get right. When the people charged with enforcing the policy are unclear on its scope, the balance skews towards protection and more legitimate tasks are prevented. HIPAA permits but does not require a wide range of requests for information, so many err on the side of caution and choose not to disclose (sometimes for other reasons but using HIPAA as an excuse). Disclosure policies are left to individual health providers.

In addition to the original article, the Times also published an interview with the deputy director for information privacy for the US Dept of Health and Human Services. The interviewer asked why disclosure is left to providers, rather than included as part of the original policy. The answer was that the department was charged with developing privacy policy, not disclosure policy. The intent was for providers to develop disclosure policies, as long as they didn't violate HIPAA regulations.

The real problem here then, is not one of people not understanding HIPAA, but one of people not understanding that HIPAA is a _component_ of health information policy, but not the entire policy. Language standards for writing access-control policies, such as XACML, have evolved to support policies that handle some issues but not others. If one were to encode HIPAA in XACML, most of the disclosure cases would produce a decision called "not applicable", instead of one called "deny". This would enable the hospital to write its own policy for the disclosure cases. The hospital's overall policy would be a combination (technically, composition) of the HIPAA and local policies. Either sub-policy could issue a decision on a request for information, using the "not applicable" answer to say "this is outside my scope, let the other policy decide".

In short, HIPAA is a fantastic example of why policies need to have three possible decisions (permit, deny, not applicable) rather than just two (permit, deny). Practioners are defaulting what should be not applicables to denies and skewing the intent of the policies. Fixing this requires making people aware that HIPAA governs only a fragment of information access issues and having them learn the local policies as well as the federal one. With only a couple of policies, this isn't hard, but it is subtle: one policy is rarely enough. The trap is that, since it looks like a complete policy, is gets overapplied. The policy language has to be subtle enough to distinguish "required" from "permitted" from "disallowed". The language is there, but its subtlety, and hence information access, is seemingly lost on many people.

Snail Phishing?

I got a letter on our mortgage company's letterhead requesting insurance information on our condominium building. The letter instructs us to either fax the info (policy number and period, coverage amount, etc) or to log into a website using a PIN included in the letter. Something about the letter failed my smell test when it arrived a few days ago. Last night, I looked more closely.

The company's logo looked like a bitmap image (grainy), rather than an original. The zip code on our unit is wrong (though our mailing address was fine). The url we were to visit wasn't either of the two that I know our mortgage company to use, and the state in the return address from the company matched none of our other documents from them. The letter also claimed its purpose was to ensure "prompt and accurate processing of our condominium insurance", but we hadn't asked anyone to process insurance for us. It just didn't add up.

We were able to construct explanations for most of these oddities: owners don't necessarily live at their properties, so our mailing address and unit address were probably two separate database fields, with one of them entered manually. Collecting insurance info could be outsourced to another company in another state that creates letterhead from bitmaps of its clients' real letterhead. The letter could have been poorly written. And we weren't able to construct a plausible identity attack that would want the insurance info on our whole condo building (as opposed to our unit).

So I called our mortgage company using the number from their website rather from the letter. A maddening sequence of menus later (on which I got the same options at multiple levels), I get to a customer service representative who checks the notes on my loan file and finds no mention that they've requested this info. She advises me not to comply. I ask how I should go about reporting this to their fraud department, but she says they don't have one. Curious now, Shriram called the number on the letter and went as far as the menus that asked for the loan number and all 10 digits of the social-security number (giving dummy values for each). The rest of the call sounded extremely professional.

So, we are left with suspicious practices from the company requesting the info (the full SSN request), instructions not to trust the letter from a mortgage company with no fraud division, and several small signs that our mortgage company isn't as polished as it could be. Friends who have had several mortgages reported being asked for similar info on a regular basis. We are going to return the letter with a note that the mortgage company has no record of requesting this info and advised us not to comply.

There's a real business lesson in here though about how to create the perception of security and trust. If this request is legit, the company has a lot to learn about preempting concerns about identity theft and phishing; if not, they need a fraud department. Either way, the constant hum of data threats raises the stakes on companies that may just be catching up with the infrastructural aspects of IT. These psychological questions will become only more relevant if more people develop the sensors that triggered my night of investigation.

Perception and Security

In the recent story about the airline passenger with a serious TB strain, the passenger got back into the US despite a border alert to detain him at entry. The border agent who processed him knew of the alert, but let him through because the agent decided he didn't look sick.

In my quest to understand human decision making about security, I've been reading a book on Human Judgment and Social Policy (by Kenneth Hammond). The book discusses two competing theories of truth: in the coherence theory, truth is based on logically consistent conclusions derived from facts; in the correspondence theory, truth is based on accuracy relative to observation (such as our expectations for weather reports). Neither theory is superior in all situations. However, the correspondence theory apparently works fairly well with perceptual observations, but not as well with abstract or conceptual observations.

The border incident seems an excellent example of the last point: the agent relied on his perceptual assessment of the suspect's health, rather than on the conceptual warning that he could be very sick. The agent expected TB to manifest itself visually. Even growing up in a time and place with no serious TB threat, I hear "TB" and imagine people with sunken faces and furious hacking coughs. That image persists despite my recent reading of Mountains Beyond Mountains (Tracy Kidder's engaging book about Paul Farmer's fight against disease in impoverished areas). If the agent had similar associations, he might reasonably conclude that the suspect probably wasn't sick.

Ultimately, this case shows the tension between security and convenience. When I want security, I'd expect border agents to be at least as strict as the warnings (detain additional people as they judge necessary, but adhere to all alerts). When I want convenience, I'd like to see them use their judgment and not hold up people or the processing line when they see no credible threat. In this specific case, with a particular person named, the decision should have favored security. But so many of our security policy statements are phrased much more vaguely (such as the now common airport refrain urging passengers to report suspicious people or bags to authorities). Interpretation must be allowed to navigate these cases which cannot be described precisely. I'd love to see some reporting on this case that discusses this context and tries to get at the relationship between specificity of warnings and how they get applied.