Christiansen's IT Law: Information Law Theory and Practice

Our Dysfunctional Health Care System: A Different Kind of Information Problem

2010-09-30T17:19:00.000-07:00

I don't just work on health care from an IT angle; I also sometimes work on payment issues. And in this context it has occurred to me that we have also have information problems. They're a little different from the kind you get in IT, but some day, when we have resolved all our problems in building out IT infrastructure (yeah, right), it will be all about the content. That's the real point of IT anyway, isn't it?

Well, whatever. But I recently had what I thought was some interesting correspondence about the problem of information asymmetry in health care. The presenting problem was, what are reasonable health insurance administrative costs?

This is one of the areas in which analysts often tell us we may be able to save some money. After all, what is it that health insurers contribute, and why should we pay for them?

However, you can't figure out what the reasonable cost of anything might be, unless you can figure out what you're paying for. This question which immediately brings up a whole set of deeply embedded, problematic issues of long standing.

- There are a lot of variables and interactions in complex interaction, making it difficult for even the experts to accurately assess and predict the implications of policy changes, or for that matter the implications of continuing the status quo;

- The average person, even the average educated person who’s trying to pay attention in good faith, and definitely including the average policymaker, including those trying to act in good faith, probably doesn’t have the background or experience to know what the facts and issues are in any depth;

- There are very strong, well-organized financial interests playing an ultimately zero-sum game (healthcare expenditures cannot actually go up forever);

- Healthcare issues are valuable partisan footballs, perhaps especially when they are distorted; and

- The mainstream media hasn’t, with a very few exceptions, sufficient expertise to clarify the issues.

This makes it, ahem, difficult to get agreement on exactly what any data show. But here are a few thoughts, anyway.

In the first place, I personally don’t believe it’s possible to have a genuine free market for healthcare goods and services, if by that is intended a marketplace in which individuals consumers purchase goods and services, and their purchasing decisions set a price which is accepted as politically legitimate. The healthcare market is subject to too many information asymmetries – individuals don’t and frequently can’t know what they need or the factors they ought to consider – and motivational asymmetries – how much are you really going to haggle over the price of treatment for that cancer that will kill you if you don’t get it? How about if it’s your daughter?

I also don’t think culturally the US is ready to simply state that in healthcare you get what you can pay for, and if you can’t afford it that’s your own problem, period. (Personally, I’m rather glad of that.) Nor do we have anything like an adequate charity safety net – I’m not sure we could, without charitable institutions becoming a much larger sector of the economy. Unless we are willing to live with the political, social and moral consequences of trying to enforce a consumer-based healthcare marketplace, we need some other mechanism to set healthcare prices.

(Editorial comment: The only reason markets in anything important are allowed to exist is because their pricing results are accepted as politically legitimate. Whenever they are not, for important goods or services, for a material portion of the population, for a material period of time, political intervention is inevitable. You can argue it *shouldn’t*, but I would argue that that is an ideological position, and history shows this happening time and again.)

This is why we have health insurance: To set healthcare prices by negotiating (in the larger sense) with providers. You could do this differently, of course; single payer is the obvious alternative, with a single entity to do all the purchasing negotiation. Or you could simply set prices by government fiat. Whatever the possible merits of such approaches, the US doesn’t do it that way, and clearly isn’t going to go there in the current round of reforms.

The core administrative functions of health insurance companies are all related to healthcare price negotiations. Claims management is ultimately a set of processes for making sure the “right” price is paid for a given set of products and services; prior approval is a process for negotiating the purchase of specific products and services; underwriting is a process for making sure the insurance company takes in enough funding to pay for predicted payments; and so on. In all of these activities, the insurance company is negotiating from a position of lower information and motivational asymmetry than individuals would; it may not know as much as the provider does but it knows a lot more than an individual, and for better or worse it certainly doesn’t care the same way the individual does. (This is probably the main reason people hate insurance companies – they will deny care that individuals are motivated to want.) Of course, the same is true for a single—payer or government fiat solution.

In this context one of the valid arguments against private insurance companies is that they have additional non-core administrative functions, such as marketing, that don’t (or aren’t seen to) support their core functions. Conversely, one of the valid arguments against single-payer and government fiat is that they tend to inflexibility: This is what we do, take it or leave it. Personally (that word again), that is the reason I tend to favor continuing private insurance: The companies are likely to adapt more flexibly and may be more likely to support valuable new approaches, e.g. better case management and wellness programs, which reduce claims by creating incentives for healthcare strategies which may actually be *experienced* as better by individuals, and contribute to their actual health.

Having said all that, of course in practice actual markets are often dysfunctional for many reasons, and it’s not as if there’s much of a competitive health insurance market. Dysfunctional markets tend to receive political intervention (see above), and maybe in the final analysis this market is so concentrated that only governmental intervention (or the threat) can bring about key features which serve individual consumers better . . .

So, I think the data show that managed care and health insurance are part of the health care pricing problem (due to their own market concentration) *and* part of the solution (due to the dysfunctionality of the healthcare products and services).

What's my solution? Hey, if you've got a good one, let me know!

Preliminary Thoughts on the HITECH/HIPAA NPRM: Modifications to the HIPAA Privacy, Security, and Enforcement Rules under the Health Information Technology for Economic and Clinical Health Act

2010-07-08T15:31:00.000-07:00

The Notice of Proposed Rule Making (“NPRM”) for the proposed new regulations amending the HIPAA regulations as required by HITECH have just been informally published here. The formal publication date in the Federal Register is probably going to be July 14, 2010. This is a brief heads-up on a few issues the NPRM seems to present.
Introduction.

At this point I think the following are the key points:

• The most significant innovation is that the NPRM proposes comprehensive regulation of all entities which obtain or use PHI to perform activities or functions serving Covered Entities, whether they are Business Associates or Subcontractors (a newly defined term) of Business Associates. It no longer matters where the entity falls on a chain of contracts, or even if there is a contract in place, any entity which fits this description will be regulated and subject to penalties for failure to comply. Of course, failure to have a required Business Associate Contract in place would create a lot of HIPAA violations.

• Business Associates – including Subcontractors now, so this means all entities which obtain or use PHI to perform activities or functions serving Covered Entities, regardless of their contract status – will have to be in compliance with the Security Rule, as well as the other Business Associate compliance obligations HITECH imposes, by the date which is 180 days from the date the final rule is published. However, I believe (subject to further analysis) that all Business Associates including Subcontractors will be subject to the breach notification rules as of the date the final rule is effective.

• Business Associate Contracts which are compliant with the existing rules and in effect before the date the final rule is published will be grandfathered and “deemed compliant” for the next year and 240 days from the date the final rule is published. Business Associate Contracts which are entered into or renewed or modified after the date the final rule is published will have to be compliant with the new standards. “Evergreen” Business Associate Contracts, which renew automatically without changing, are not considered to be “renewed” for this purpose.

• My impression is that there will be a number of good reasons to want to come up with new Business Associate Contract forms to deal with the new standards and arrangements.

• Business arrangements where revenues or other remuneration are tied to PHI use or disclosure will be subject to closer scrutiny and will have to comply with some new limitations. While this shouldn’t disallow most such arrangements – though it probably will do so for some – most such arrangements should be reviewed to ensure compliance, and appropriately documented.

• We have some potentially useful new enforcement standards proposed, which clarify how violations will be classed. The upshot is, as is typical in compliance matters, that documentation of decisions and policies will be important to avoiding liability.

The NPRM also proposes regulations in a few other areas which may be important to some organizations or in some contexts.

Because this is a NPRM these proposed rules are not actually the provisions which will be required for compliance. The proposed rules are being published for comment, and final rules will published after review of the comments. Comments may be submitted for sixty days after official publication, through September 12, 2010. There is no set date for publication of final rules after that.

The effective date for compliance for the HITECH provisions to be clarified by these rules was February 18, 2010 under the legislation, which obviously has passed. In order to allow for a reasonably orderly transition DHHS has provided an extension of the compliance date through the date 180 days from publication of the final rules, for most of the regulations requiring action by Covered Entities or Business Associates. I think this probably won’t apply, however, to compliance with the breach notification regulations which were effective last September; Covered Entities and Business Associates are already subject to those.

Business Associates and Subcontractors.

The most significant changes, as expected, apply to Business Associates and “Subcontractors.” As expected, the NPRM clarifies a number of points around HITECH’s extension of HIPAA regulatory jurisdiction to Business Associates. However, the NPRM also proposes to extend the same requirements to Subcontractors of Business Associates as well. This is a potentially very significant additional extension of jurisdiction. Understanding why requires a bit of review of the “Business Associate” concept.

A Business Associate is a concept created under the initial HIPAA regulations intended to extend HIPAA’s PHI protections to information obtained by non-Covered Entities to perform activities on the Covered Entities’ behalf. The regulatory definition is therefore that a Business Associate is any “person” performs any function or activity on behalf of a Covered Entity involving the use or disclosure of PHI. Because HIPAA did not provide for jurisdiction over entities other than the statutorily established Covered Entities, the initial HIPAA regulations extended protections indirectly by requiring Covered Entities to have a specific form of contract, the Business Associate Contract, in place before allowing their Business Associates access to PHI. If the Business Associate violated the contract and did something improper with the PHI the Covered Entity was required to take actions up to and including contract termination, and the Covered Entity (but not the Business Associate) could be penalized for failure to do so.

Of course, sometimes Business Associates also need additional parties to perform functions or activities involving PHI they have on behalf of a Covered Entity, and under the initial HIPAA regulations a Business Associate Contract could include a provision allowing them to do so if they “ensure that any [such] agent, including a subcontractor” agrees to the same “conditions and restrictions” as apply to the Business Associate under its Business Associate Contract. This has generally been interpreted as a much looser standard than the Business Associate Contract requirements, and practices in this area have often been fairly relaxed.
Under the NPRM this will change, because the NPRM proposes to extend jurisdiction to Subcontractors of Business Associate, by defining them also as Business Associates and requiring Business Associates to have Business Associate Contracts with their Subcontractors. (Yes, this will be confusing to figure out, and take some analysis of the NPRM to see how it works and if there are any strange logical loops, etc.)

“Subcontractor” is now proposed to be defined as a “person who acts on behalf of a business associate, other than in the capacity of a member of the workforce of such business associate.” The definition of Business Associate is also now proposed to be modified to add Subcontractors, even though they do not have a direct relationship to the Covered Entity. Since a Subcontractor is now defined as a Business Associate, it logically seems that any person which acts on its behalf performing a function or activity involving PHI is also a Subcontractor, and therefore a Business Associate.

In other words, in any activity or function involving a chain of relationships among entities, there will need to be a chain of Business Associate Contracts. One effect of this change would therefore seem to be a broad expansion of the use of Business Associate Contracts throughout the health care sector, probably to many types of entity which never had to have them before. Less visibly, acting as a Subcontractor (even without a Business Associate Contract in place) will automatically bring an entity under HITECH/HIPAA jurisdiction, including required compliance with all the rules applicable to Business Associates.
Grandfathered Business Associate Contracts.

It will likely take some work to develop good Business Associate Contract forms for this purpose, and my impression is that due to these and some other changes it will be desirable for Covered Entities also to revise their forms. The good news, however, is that most Covered Entities and Business Associates should currently be in compliance if they have appropriate Business Associate Contract forms in place, and will have some time to implement new forms.

The NPRM proposes Business Associate Contract transition provisions which would “grandfather” Business Associate Contracts which are in place as of the date of publication of the final rules, as long as the contract is not renewed or modified during the period from sixty days from the date of publication of the final rules through the date 240 days from that date. Grandfathered contracts will then be considered compliant until the earlier of (1) their “renewal or modification” after the 240 day period, or (2) the date one year and 240 days from the date of publication of the final rules.

This is a bit confusing, but looks like it would work as follows. Assume a final rule publication date of October 1, 2010:
• Any Business Associate Contract in place before October 1, 2010 is deemed compliant (as long as it is compliant with the initial rules, of course).
• If the Business Associate Contract is “renewed or modified” at any time after October 1, 2010, the new rules will apply.
• If the Business Associate contract is not “renewed or modified,” it will have to be reviewed and possibly amended to ensure compliance with the new rules no later than May 29, 2011.

The same transition rules do not apply to other compliance obligations. In particular, Business Associates (including Subcontractors, of course) will have to be compliant with the Security Rule 180 days from the date of publication of the final rules – e.g., for a publication date of October 1, 2010, by March 30, 2011.

Business Associate Security Compliance.

There is some good news for Business Associates around Security Rule compliance, however. Business Associates will be fully required to comply with the Security Rule, as required by HITECH. However, the NPRM clarifies that Business Associates are to determine the safeguards they implement based on the “flexible factors” and “addressable specifications” applicable under 164.306 of the Security Rule. This was not clear under HITECH.

This is a helpful clarification, but does mean that Business Associates will need to document their security decision-making in more depth than they may be used to. My suspicion is that many Business Associates – especially Subcontractors which have been able to operate outside the sphere of HIPAA. This kind of Subcontractor may also not be ready to deal with the security breach notification regulations, which will kick in only 60 days after the final rules are published.

Business Arrangement Implications.

The extension of regulatory jurisdiction to every entity which uses PHI for some activity or function which serves a Covered Entity is likely to cause some entities to take a serious look at how they do business. This may become even more significant for those which are involved in processes such as data mining and other secondary uses of PHI and PHI-derived data.

Some entities may even wind up becoming regulated without knowing it, if they are far enough down a contract chain and don’t have controls to identify the sources of information they receive. This can be shown by an example given in the Preamble to the rule, where a third party administrator (“TPA”) acting as a Business Associate to a health plan contracts with a document and media shredding company to destroy records including PHI. The shredding company is a Subcontractor, and therefore a Business Associate, and therefore regulated – but won’t know that unless the TPA tells it so, or it reviews the information it is shredding and can ascertain that it is PHI from a Covered Entity which has contracted with the TPA (something the shredding company shouldn’t be doing in the first place).

A wider range of entities providing services to the health care sector than those which already know they are Business Associates should probably consider their business models, and if they involve PHI consider whether they can modify their model to avoid regulation (by avoiding PHI), or if not how they will have to adapt it to the new rules. In this connection many will also need to look at financial models, if they are at all tied to PHI (e.g. per-records processing fees, etc.), since these too are proposed to be more tightly regulated.
HITECH included a directive for regulations tightening up the sale of PHI and its use PHI for marketing, and the NPRM makes some helpful clarifications in this area.

Part of this clarification, however, is to propose standards in an area which has to date been fairly loose. The rule is now clear that individual authorization is required for the disclosure of PHI in a “sale,” unless it fits one of several specific exceptions. This rule applies whenever PHI is disclosed in return for “remuneration,” a very broad term which covers any kind of compensation. While the exceptions are intended to allow for ordinary and legitimate transactions, there are likely to be some existing arrangements which don’t fit.

Conclusion.

The NPRM presents a few other issues, and from a lawyer’s point of view some of the clarifications around enforcement standards are also helpful. Other issues not yet identified are bound to crop up, especially as we begin working through the implications. While these are not final regulations and compliance is not required, my recommendation is that entities in the health care sector – especially Business Associates, under its expanded meaning – take a careful look at possible implications for their own activities. They may find undesirable implications and want to comment, and hope their concerns will be resolved; and in some cases they may want to start planning a reorganization to change their business model or begin planning to adapt to the new reality.

Overall, my impression is that the NPRM is very consistent with the agenda of increased regulation of secondary players in the health care sector, to enable increased use of electronic health records and health information exchange. In legal terms I think it is a significant step toward that goal. I am sure there will be some changes based on comments, but I frankly would not expect important additions or deletions. I expect the final rule, which I would guess will issue some time this Fall (but it is only a guess) will be very consistent with the NPRM, so this is the shape of things to come.

HITECH Incorporation by Law: A Painful Conundrum

2009-12-17T16:41:00.000-08:00

Okay, here’s yet another HITECH question: What does it actually *mean* if HITECH BA requirements are both applicable as a matter of law, and required to be incorporated into BACs? Do we have any discretion to vary the BAC language from the legally incorporated language?

We’ve all (well, many of of us) read the argument about why HITECH’s “shall be incorporated” language can properly be interpreted to the effect that the included requirements are incorporated in BACs as a matter of law. In fact, HIMSS sent comments to OCR to that effect, which were essentially a well-reasoned legal argument. I haven’t confirmed the legal research or checked for alternative legal theories – I do have to do paying work too – but knowing the folks who prepared and reviewed it I expect it’s sound. I think the language is at least ambiguous, in that it “shall be incorporated” can also be interpreted as a command (“the parties shall incorporate”), but the other position clearly has good support.

Automatic incorporation is a helpful position for one significant problem, that of BAC amendment. CEs with a lot of BAs (and BAs with a lot of CEs) already face a burdensome and annoying project in identifying and updating existing contracts, no matter what the timeline. If they have to do it by February 17 this burdensome project will become very difficult and perhaps in some cases impossible within the allotted time. If existing BACs are considered compliant without amendment because new HITECH requirements are incorporated by law as of their effective date, however, this problem is alleviated. Given this useful result and well-reasoned arguments for the automatic incorporation position, OCR could well adopt it.

If so, however, what happens to BAC provisions which deviate from the language of the automatically incorporated requirements? There may be a number of situations where this makes sense – certainly my own view is that it is preferable to write BAC requirements in terms consistent with contract interpretation and enforcement and the parties’ actual operations, because statutory and regulatory language is not necessarily well-adapted to the kinds of interaction and services standards and definitions and dispute resolution needs contracts are intended to serve.

But if we are under a regime where statutory or regulatory requirements are automatically incorporated, in the statutory or regulatory language, does that mean that differing contractual language is:

1. Per se invalid?

2. Invalid to the extent it changes a material aspect of the incorporated requirement? If so, what might be material?

3. A violation of HIPAA/HITECH because it is in whole or in part invalid? If so it would be a continuing violation . . .

4. Valid, but creating an overlapping additional or supplementary requirement to the extent it is materially different from the incorporated requirement?

5. Something else that hasn’t occurred to me?

I don’t know but I think I better try to figure it out.

In fact, I think I better figure it out *even if OCR guidance states that automatic incorporation is not the rule.* In another HITECH strange loop, this problem also affects *existing* BACs, to the extent the language of those provisions deviates from the language used to define the BAC provision requirements in the Privacy Rule. And the language used does not seem ambiguous, the way the “incorporation” language from 13401 and 13404 does.

Here’s the problem. HITECH sec. 13404 states:

In the case of a business associate of a covered entity that obtains or creates protected health information pursuant to a written contract (or other written arrangement) described in section 164.502(e)(2) of title 45, Code of Federal Regulations, with such covered entity, *the business associate may use and disclose such protected health information only if such use or disclosure, respectively, is in compliance with each applicable requirement of section 164.504(e) of such title[.]*

The last clause appears to me to make the “applicable requirements of section 164.504(e)” legal obligations of the BA, *independent of the BAC.* These obligations are the established BAC requirements – which therefore now are independent statutory requirements which parallel, overlap or perhaps override the same requirements in *all BACs*, to the extent the language in the BAC may vary from the regulatory language of the BAC requirements. (Though I’m not actually sure we’ve got the potential variation invalidity problem, since we don’t have the “incorporation” language – but I do think organizations could face a “deviation = additional obligations” problem.)

Upcoming HIPAA Business Associate Presentations

2009-11-24T13:27:00.000-08:00

I will be presenting as follows:

December 4 audioconference, HIPAA Ethics Update: Lawyers in the Compliance Crosshairs

December 15 audioconference with Alan Goldberg and Alan Freivogel, Attorney Business Associates:
February 17, 2010 Is Almost Here – Are You Ready Now?

Requesting Copies of Presentations and Articles

2009-11-24T12:59:00.000-08:00

I've had a couple of folks mentioning an interest in copies of presentations or articles I've done. I'm often happy to make them available, but don't really have a way to get them to you if I don't have your email address. Understandably, nobody wants (or should want) to leave their email address in blog comments, so if you also don't publish one as part of your profile and would like to request something here's a suggestion: Go to the Christiansen IT Law website and email me via the "Email John" button.

Thanks!

How to Eliminate the Barriers to Health Information Exchange

2009-11-20T10:04:00.000-08:00

I know how to eliminate the principal barriers to health information exchange (HIE): A clear code of safety standards and insurance.

The real barriers aren’t really technical any more. We do have challenges in terms of electronic health record (EHR) interoperability and in some other areas, and they are not trivial. But there is a lot of work going into standards and other requirements to achieve interoperability, and in any case this is more a question of data standards than data exchange. These problems of information content are not really barriers to the technical exchange – the transmission and receipt – of information.

The real barrier to HIE is risk aversion: Health care providers, in particular, are often reluctant to buy EHRs and participate in HIE because they fear they will be held liable if the information they hold, transmit and receive goes astray or is misused. This risk aversion is usually expressed in terms of a lack of legal standards – I’ve been through seemingly endless analyses of federal and state laws potentially applicable to HIE, to try to reconcile them and find a way to assure clients that they can do HIE safely, or at least that we can roughly quantify their legal exposures associated with it. This is a difficult task because the laws are neither written nor organized in ways which tell you the rules for legally-compliant HIE – that is, they don’t describe how a provider can conduct HIE with at least a reasonable assurance that they won’t face legal liability.

The situation is rather as if we had built our existing road system backwards, starting with superhighways and then asking people used to horses and buggies to start driving on it in Corvettes and 18-wheelers. Worse, it’s as if we had partially built our interstate highway system, but hadn’t bothered to figure out things like stop and yield signs, and what speed limits are safe for curves and hills. Drivers who aren’t particularly risk-averse – they don’t recognize the risks, or don’t care about them much – might happily hop into their Corvettes or big rigs and start cruising. After a few crashes, maybe we begin to learn that we need some kinds of road signs and some speed limits, and start putting them up. We might even decide that driver’s education is a good idea, and that drunk driving is to be seriously discouraged.

Over time we’d evolve safety standards for our superhighway. We’d probably put up some useful signs, and they would get more useful over time. Curves where a lot of crashes occur would probably get straightened out, and drivers would learn how to handle their vehicles better. But during the evolution of these safety standards, a lot of prospective drivers would probably figure, I’ll stick with my horse and the back roads until they work out the bugs.

For the truly risk-averse, even a well-designed superhighway with good signage and licensed drivers might still be too daunting. Driving is an inherently risky business, even if you have good safety standards and are diligent about their enforcement; road conditions can vary, even good drivers are sometimes negligent, and unanticipated conditions can crop up. Accidents and intentional malfeasance happen, and the only way to avoid the risk altogether is by avoiding the highway.

This is why every state requires all drivers to have insurance: To pay the costs associated with the statistically inevitable harmful incidents associated with driving. This includes costs of repairs to your vehicle – and you yourself – as well as covering harm to as third parties. The system is no-fault in the sense that coverage does not depend on who is or may have been at fault, so drivers and third parties don’t have to worry about payments being delayed while insurers squabble over who have to pay what amount. Of course, the system isn’t perfect, and insurers still do dispute fault, but at that point it’s really about how the insurers split coverage, not about whether coverage exists. And, usefully for the determination of such disputes, safety standards help decide who, if anyone, was actually at fault.

Safety standards and insurance will not work for the extremely risk-averse, of course. For some, the advantages of swift movement from place to place will not outweigh their fear of a crash – or of the unknown – and they will want to stick with their horse and buggy. But clear safety standards and insurance are likely to be enough to overcome risk aversion in most individuals.

So how would this work for HIE? Well, we’ve already built an Information Superhighway (thank you for the metaphor, Al Gore) – the Internet – which, frankly, does not have a lot of built-in safety features. So we need to come up with standards for its safe usage for HIE (which could and probably should apply to proprietary networks used for HIE too, of course). These standards need to be clear enough to translate into policies and procedures healthcare organizations can understand, implement and explain to users. Users need to be trained in these standards – and maybe we should consider whether users should be qualified in some way as a condition to engaging in HIE. (They already should be by any organization which authorizes them to participate in HIE on its behalf, but perhaps we need broader requirements.)

Standards need to be enforced, and we need mechanisms for learning from accidents, mistakes and deliberate malfeasance. At the same time, organizations need assurance that if they comply with standards they will be safe against penalties and damages – that they will be considered compliant with the law, and with applicable standards of care. Safe harbors and standards maintenance and evolution will be essential.

We should also look into insurance to cover the statistically inevitable. Part of this is coverage for the organizations themselves, for matters such as incident response and breach notification, and remediation. But the really valuable insurance would be against third-party harms – harm to individuals whose personal health information is misused or improperly disclosed in the course of HIE (or EHR usage).

This kind of insurance will take some work to develop. We already have insurance available for misuse of personal financial information. The most commonly known covers credit monitoring and in some cases cure of misinformation, but this kind of insurance is in fact less important than the “hidden” insurance provided by payment card issuers’ guarantees to consumers against credit card fraud. This risk transfer in fact enabled electronic commerce in general, by limiting consumers’ exposure to fraudulently created debts to fifty dollars (and usually not even that). Even risk-averse consumers could, and did, use the Information Superhighway to start buying online, because the issuers assumed their risks of doing so. Of course, over time even massively well-capitalized companies like the payment card issuers want to limit their exposure, and they have in turn started requiring vendors using payment cards to implement specific security requirements – in effect, private safety standards for ecommerce, not an uncommon role for insurers to play.

So, I have the solution for the principal barrier to HIE: We need clear safety standards, and we need insurance.

Now all we need is a good standards body with clear legal standing, and a well-capitalized organization to fund coverage . . .

(Thanks to Peter Winn for the conversation and Kirk Bailey for the tilting at the windmills which inspired this piece.)

More HIPAA/HITECH and Joint IT Environments: Multiple Account Access

2009-11-14T15:19:00.000-08:00

I've had some interesting follow-up from my previous posting about HIPAA/HITECH and cloud computing. One question was about my statement that users authorized by one Covered Entity whose Protected Health Information and applications are hosted in a joint IT environment shouldn't have access to the Protected Health Information and applications of other Covered Entities hosted by the same services provider. A question of particular interest was whether that statement also applied if the access was for purposes of treatment, payment or healthcare operations, or if the two Covered Entities were part of an organized health care arrangement (OHCA).

This is an issue I’ve gone around several times with ASPs and RHIOs, and I don’t think it would be either prudent or permitted by HIPAA for different Covered Entities to simply “leave the door open” for external users to access data. “Access” from the user’s side is “disclosure” from the Covered Entity's side (the HIPAA/HITECH definition of “disclosure” specifically includes “access to information outside the entity holding the information”). So the Covered Entity needs to comply with HIPAA’s disclosure requirements in allowing users from different Covered Entities to access its Protected Health Information.

If the external user is a provider who needs access for treatment purposes, patient authorization is not needed and the minimum necessary rule does not apply. If the external user needs access for payment or health care operations, patient authorization is still not needed, but the minimum necessary rule does apply. That’s all good as far as it goes; you can structure policies and controls to make the appropriate information available (though minimum necessary compliance may be more of a challenge than it appears), but it begs the question, how does the Covered Entity know the purpose of the access, and that the external user is authorized to have it?

The security rule requires Covered Entities to have policies and procedures for granting access to ePHI, including documenting, review and modification of a user’s right of access. Users also have to have unique IDs and the Covered Entity has to have a method of authenticating the user. The security rule also requires security incident identification and response, while HITECH requires notification procedures for security breaches; in both cases the definition of a trigger event includes unauthorized access.

Uncontrolled access would mean that the Covered Entity would be unable to document and review an external user’s right of access, and might not be able to identify and authenticate the user. It certainly wouldn’t be able to identify unauthorized access – i.e., security incidents and breaches. So we’ve got some likely HIPAA violations, and also a lack of controls which is really inappropriate for access to sensitive information as a matter of ordinary prudence. (And I do mean that in the sense that I think it would be actionable negligence.)

When you’ve got an IT environment in which one organization is responsible for user access control, which you can have with ASPs, SaaS or cloud computing environments, that organization can be responsible for user identification and authentication and access control administration. What it probably can’t do is authorize users to have access to ePHI – it has to be told about this by the Covered Entities, who know the roles of the users, etc.

What you need then is a mechanism to make authorization transitive – to allow Covered Entity A to accept the authorization of an external user by Covered Entity B, to access ePHI owned by A on B’s behalf. This is where it often gets sticky, and RHIOs have fallen apart, because generally speaking A won’t (and probably shouldn’t) accept an authorization from B without B assuming liabilities for error and indemnifying A. This can be overcome – I’ve set up a number of arrangements which make it happen – but it can cause serious conflicts between A and B.

I don’t think an OHCA helps with this issue. The real issues are under the security rule, which does not work in those terms. But that doesn’t mean that entities within an OHCA can’t agree to manage data access appropriately under the security rule – e.g. a health system might manage identification and authentication functions on systems it supports, which allow users from associated clinics access to its systems, and in turn the clinics could use the same I&A solution to control access for hospital users accessing theirs. (There are also a few third-party I&A services which can be helpful.)

HITECH/HIPAA Obligations of Cloud Services Providers

2009-11-13T09:24:00.001-08:00

Background: HITECH sections 13401 and 13404 now apply certain HIPAA and HITECH security and privacy requirements to business associates (BAs).

Scenario: Company A provides healthcare administrative or electronic health record (EHR) systems through the cloud, or SaaS. Company A is therefore by definition a BA.

Question: Is Company A therefore responsible under HITECH for making sure its covered entity (CE) customers follow any specific policies and procedures for access to the hosted systems? What if the CE wants to do it in a way that violates the HITECH/HIPAA privacy or security rules? Does Company A have any obligation to police its customers?

My Answer:

1. I would characterize cloud services/SaaS as a joint IT environment. This places HIPAA/HITECH obligations on both services provider and customer.

2. One complex part of the answer is that the business associate obligations depend crucially on the terms of the business associate contract (BAC) which HIPAA/HITECH requires these parties to have. This gets into thorny questions I don’t want to address here - for now I would only say that I think you need to draft such contracts very carefully lest you set up regulatory obligations which are neither necessary nor appropriate, and might expose either or both parties to avoidable civil penalties and other liabilities.

3. Apart from BAC obligations, HITECH does create security obligations for BAs with responsibility for joint IT environments. These obligatios might well include an obligation to establish safeguards intended to ensure that users associated with one CE do not access services/PHI owned by another CE. CEs in fact, in my view, ought already to require this – that is my practice, working both with CEs and with vendors which operate joint IT environments for CEs. If Company A provides services in this way, it would have an obligation to stop - and to some extent prevent - CE user activity affecting other CEs.

4. As to policing CE user activity affecting only services/PHI of the same CE, I don’t think there is a per se answer. The BA might take on some safeguard services, maybe such as user registration, which would put it in a position where it might need to enforce CE policies. If CE policies seemed to violate the privacy rule, that might trigger issues for the BA under the new HITECH termination/snitch provision of 13404(b).

Conclusion: BA obligations in this area have to be analyzed specifically in terms of the services provided, with an eye to the obligations assumed by the BA and the BA’s ability to be on notice of an improper practice. In an “ordinary” cloud/SaaS model, the BA probably won’t have sufficient information to be able to identify CE violations, and probably wouldn’t want to assume responsibility for doing so. But avoiding this obligation will often require specific functional analyses of the operational model, and careful drafting of the contract.

In other words, don't try this at home, kids.

HITECH and Business Associate Compliance - The Key Points

2009-10-27T11:47:00.000-07:00

The following is an outline of a presentation I've done on new Business Associate compliance and risk issues under the Health Information Technology for Economic and Clinical Health Act (HITECH), the portion of the American Recovery and Reinvestment Act (ARRA) dealing principally with electronic health records (EHRs).

HITECH compliance is both possible and necessary, but needs to be approached with care, a willingness to analyze difficult legislative provisions, and a sense of humor. Professional help is highly recommended. If you are so inclined, an alcoholic beverage after a HITECH work session - not before! - is also recommended.

If you'd like a copy of the presentation let me know and I'll send it along. Good luck!
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

What Is HITECH?

1. Title XIII of the American Recovery and Reinvestment Act of 2009, H.R. 1, Pub.L. 111-5 (February 17, 2009)

a. “ARRA” or “the Stimulus Bill

b. 407 pages

2. Title XIII of ARRA: Health Information Technology for Economic and Clinical Health Act – “HITECH Act”

a. 53 pages

3. Subtitle D: Privacy

a. 21 pages

ARRA was principally intended as stimulus vehicle. HITECH was drafted principally to provide funding for electronic health records (EHRs) and related activities. Subtitle D was added to provide additional legal protections given increased use of electronic systems for healthcare use. My opinion: It was hastily drafted, will be hard to interpret in some cases, and will have unintended consequences.

Compare: HIPAA Administrative Simplification was principally intended for claims processing reform, and wound up reforming healthcare privacy and security.

B. Principal HITECH Concepts (in order of current importance)

1. Extend regulation over key healthcare IT players (Business Associates)

2. Create new security breach notification requirements

3. Increase penalties and tighten enforcement

4. Tighten some PHI use and disclosure limitations

5. Tweak patient/consumer data access rights

C. Business Associates Overview

1. The Old Business Associate (BA) Rules

As a matter of jurisdiction HIPAA applies only to Covered Entities (CE), defined by statute to include health plans, health care clearinghouses and health care providers. See 45 CFR § 160.103

The “Business Associate” (BA) was therefore created to allow CEs to use non-Ces to work with Protected Health Information (PHI) on their behalf, without the PHI losing legal protection. A BA is therefore defined as a person to whom a CE discloses PHI so the person can carry out, assist with, or perform a function or activity on behalf of the CE. 45 CFR § 160.103. BA examples include:

· Claims processing, transcription service, application services providers, utilization review, quality assurance, etc.

· Legal, actuarial, accounting, collections, consulting, accreditation, financial, etc. services

· “Any other function or activity regulated by” HIPAA

2. The Old Business Associate Contracts Rules

A CE may disclose Protected Health Information (PHI) to/allow a BA to create or receive PHI on CE’s behalf upon “satisfactory assurance” BA will “appropriately safeguard” PHI. 45 CFR § 164.502. A “satisfactory assurance” is a Business Associate Contract (BAC) including required provisions (or equivalent memorandum of understanding if governmental entities, plan document provisions if group health plan). 45 CFR § 164.504(e). A BAC must include the following provisions:

· Establish permitted uses/disclosures of PHI by BA on behalf of CE, and may permit it for “proper management and administration” of BA

· Prohibit PHI uses/disclosures not permitted by BAC, or “as required by law”

· BA to use “appropriate safeguards” to prevent non-permitted uses/disclosures of all PHI, and implement “administrative, physical and technical safeguards” to protect confidentiality, integrity, availability of electronic PHI

· Report to CE any non-permitted use/disclosure of PHI, and any “security incident of which [the BA] becomes aware”

· Ensure that BA agents/subcontractors agree to same “conditions/restrictions” as BA, and implements “reasonable and appropriate safeguards to protect it”

· Makes PHI available for individual access and amendment, and provide for accounting of disclosures

· Make BA “internal practices, books and records” available to DHHS for review in determining CE’s HIPAA compliance

· Provide for return/destruction/”escrow” of PHI upon termination of BAC

· Authorize termination of BAC if CE “determines” that BA has “violated a material term” of the BAC

45 CFR §§ 164.314(a), .504(e)

PHI protection is enforced because a CE may be penalized if CE “knew of a pattern of activity or practice” of the BA “that constituted a material breach or violation” of the BAC, unless:

· The CE took “reasonable steps to cure the breach or end the violation” and, “if such steps were unsuccessful:”

· Terminated the BAC, if “feasible,” or if not “feasible” reported the problem to DHHS

45 CFR §.504(e)(1)(ii). HIPAA provides no jurisdiction to penalize BAs.

D. The New HITECH BA Rules: Summary

1. Subtitle D incorporates the following HIPAA regulatory terms incorporated by reference

· Business Associate, Covered Entity, disclose, health care operations, health plan, health care provider, payment, protected health information, use

2. BAs are now required to comply with HIPAA security regulations, and HITECH security requirements

3. BAs required to comply with HITECH privacy requirements

4. HITECH privacy and security requirements incorporated in BACs

5. BAs required to terminate BAC or notify DHHS of CE breach or violation

6. BAs may be audited by DHHS

7. BAs subject to civil and criminal penalties for HIPAA privacy or security regulation violations

E. Business Associates Security Drill-Down

1. BAs are now required to comply with the HIPAA Security Rule:

Sections 164.308, 164.310, 164.312, and 164.316 of [the HIPAA security regulations] shall apply to a business associate of a covered entity in the same manner that such sections apply to the covered entity. The additional requirements of this title that relate to security and that are made applicable with respect to covered entities shall also be applicable to such a business associate and shall be incorporated into the business associate agreement between the business associate and the covered entity.

HITECH § 13401(a)

2. The regulations Included for compliance are the following:

a. 45 CFR §164.308: Administrative safeguards

i. Standard: Security management process

A. Specifications

I. Risk analysis ®: “Accurate and thorough assessment of potential risks and vulnerabilities”

II. Risk management ®: Security measures “sufficient to reduce risks and vulnerabilities,” to ensure confidentiality, integrity and availability, protect against reasonably anticipated threats or hazards, protect against improper uses or disclosures, and ensure workforce compliance

III. Sanction policy ®: Against workforce for failure to comply with security policies and procedures

IV. Information system activity review ®: Regular review of audit logs, access reports, security incident tracking reports

ii. Standard: Assigned security responsibility

A. No separate specification; identify security official responsible for policy and procedure development and implementation

iii. Standard: Workforce security

A. Specifications

I. Authorization and/or supervision (A): Of workforce with access to electronic protected health information

II. Workforce clearance procedure (A): For determination whether access rights are appropriate

III. Termination procedures (A): To end access to electronic protected health information when employment terminated or clearance determined inappropriate

iii. Standard: Information access management

A. Specifications

I. Isolate health care clearinghouse functions (R)

II. Access authorization (A): Policies and procedures to grant users access to system resources allowing access to electronic protected health information (e.g. workstations, transactions, processes)

III. Access establishment and modification (A): Policies and procedures to establish, document, review and modify users’ access authorizations

iv. Standard: Security awareness and training program (all workforce, “including management”)

A. Specifications

I. Security reminders (A)

II. Protection from “malicious software” (A): Guarding against, detecting, reporting viruses, etc.

III. Log-in monitoring (A): Procedures for monitoring log-in attempts and reporting “discrepancies”

IV. Password management (A): Creation, changing and safeguarding

v. Standard: Contingency planning (emergency and “other occurrences” such as fire, vandalism, system failure, natural disaster) for information systems

A. Specifications

I. Data backup plan (R)

II. Disaster recovery plan (R)

IV. Emergency mode operation (R)

V. Plan testing and revision (A)

VI. Applications and data criticality analysis (A): “Assess relative criticality of specific applications and data”

vi. Standard: Evaluation

A. No separate specification; “technical and nontechnical evaluation,” periodic and “in response to environmental or operational changes,” of extent to which policies and procedures meet Security Rule requirements

vii. Standard: Business associates

A. Specifications (45 CFR § 164.314)

I. Contract or “other arrangement” required before covered entity “may permit a business associate to create, receive, maintain, or transmit electronic protected health information” on its behalf

a. Not required for transmissions to providers for treatment, by group health plan, HMO, health insurance issuer on behalf of group health plan to plan sponsor, or transmission to government agencies providing public benefits

B. Contract must include provisions (45 CFR 164.314(a) that:

I. Business associate will “implement administrative, physical and technical safeguards that reasonably and appropriately protect” electronic protected health information

II. Any business associate agent or subcontractor will also implement such safeguards

III. Business associate will report “any security incident of which it becomes aware”

IV. Contract may be terminated for breach of material term

b. 45 CFR §164.310: Physical safeguards

i. Standard: Facility access controls: Policies and procedures to limit physical access to information systems, while permitting authorized access

A. Specifications:

I. Contingency operations (A): Procedures for access to restore lost data under disaster recovery and emergency mode operations

II. Facility security plan (A): To safeguard facility and equipment against unauthorized access, tampering, theft

III. Access control and validation (A): Control and validate individuals’ access to facility and equipment, including visitor control and software testing/revision access control

IV. Maintenance records (A): Security-related facility elements (e.g. hardware, walls, doors, locks)

ii. Standard: Workstation use

A. No separate specification; policies and procedures to specify proper workstation functions, manner of performing functions, and physical attributes of workstation “surroundings”

iii. Standard: Workstation security

B. No separate specification; physical safeguards to restrict access to authorized users

iv. Standard: Device and media controls (hardware, electronic media)

A. Specifications:

I. Disposal (R)

II. Media Re-use (R)

III. Accountability (A): Records of “movement of hardware and electronic media and any person responsible therefore”

IV. Data backup and storage (A): “Create retrievable, exact copy of electronic protected health information, when needed, before movement of equipment”

c. 45 CFR §164.312: Technical safeguards

i. Standard: Access controls

A. Specifications:

I. Unique user identification (R): Unique name or number for identifying and tracking

II. Emergency access procedure (R): For obtaining access to electronic protected health information

III. Automatic log-off (A): Session termination after predetermined period of inactivity

IV. Encryption and decryption (A): Electronic protected health information in storage

ii. Standard: Audit controls

A. No separate specification; “hardware, software or procedural mechanisms that record and examine” system activity

iii. Standard: Integrity (protection against improper alteration or destruction)

A. Specification (A): Electronic mechanisms

iv. Standard: Person/entity authentication (confirmation of identity)

A. No separate specification; procedures to verify identity

v. Standard: Transmission security

A. Specifications:

I. Integrity controls (A): Ensure information is not improperly modified without detection

II. Encryption (A)

d. 45 CFR §164.316: Policies and procedures documentation

i Standard: Policies and procedures

A. No separate specification; may be changed at any time but changes must be documented

ii Standard: Documentation (policies and procedures; security actions, activities, assessment; in writing or electronic)

A. Specifications:

I. Time limit (R): Six years from later of creation or applicability

II. Availability (R): To individuals responsible for implementing documented procedures (presumably also to DHHS)

III. Updates (R): Periodic review, and in response to “environmental or operational changes”

3. Security regulations not included:

a. 45 CFR § 164.304: Definitions. Lack of inclusion confusing but not a problem – defined terms used in HITECH and Security Rule.

b. 45 CFR § 164.306: General rules – Security objectives, flexible approach, required vs. addressable specifications, maintenance. Lack of inclusion implies less discretion? Or nothing in particular?

c. 45 CFR § 164.314: Organizational requirements – Business associate contracts. Lack of inclusion confusing but meaningless? Is a business associate required to have a business associate contract with subcontractors or not?

F. HITECH Security Requirements Included

“This title” presumably means Title XIII – not just Subtitle D

1. Subtitle D requirements:

a. § 13401 – redundant, recursive

b. § 13401 – security breach notification

2. Other Title XIII security requirements - future standards adopted under § 3004?

G. BA Security Compliance Requirements

1. Implement security program meeting all the security regulation requirements

2. Also review CMS Sample Interview and Document Request for HIPAA Security Onsite Investigations and Compliance Reviews for supplemental perspective

3. Coordinate with CE(s) – some security measures may interfere with common or shared activities or systems

Examples: Transmission encryption, system access, authorization roles – there are others

Look for problems with differing risk tolerances

H. New BAC Privacy Rules

[A Business Associate may use and disclose PHI obtained pursuant to a BAC only] in compliance with each applicable requirement of [45 CFR § 164.504(e).] The additional requirements of this subtitle that relate to privacy and that are made applicable with respect to covered entities shall also be applicable to such a business associate and shall be incorporated into the business associate agreement between the business associate and the covered entity.

HITECH § 13404(a)

1. 45 CFR § 164.504(e): Privacy regulations BAC standard and specifications (see above)

2. Other privacy regulation compliance not required of BAs – except as provided in old BAC required provisions

3. BAC compliance now required of BAs by law

4. HITECH privacy requirements applied to BAs

a. “This subtitle” presumably means Subtitle D, not Title XIII

b. Subtitle D requirements applicable to CEs (see below) – health plan PHI disclosure restrictions, new minimum necessary provisions, new EHR accounting of disclosures rules, new patient access to information rules, new limitations on EHR sales and marketing

I. BAC Compliance

HITECH §§ 13401(a), 13404(a) provide that HITECH requirements “of this title” (security) and “of this subtitle” (privacy) “shall be incorporated into the business associate agreement between the business associate and the covered entity.”

Does “shall be incorporated” mean:

· “Are hereby incorporated by law” without further action required by the parties?

· That the parties “are hereby directed to incorporate the requirements into their BACs” by amendment or update?

No OCR guidance as of drafting date, so here are some suggestions for dealing with BACs:

· If OCR says amend, amend

· If OCR says amend right away, we have a lot of work to do fast

· If OCR says amend but enforcement will be stayed, we have a lot of work to do but hopefully more time to do it in

· If OCR says incorporated by law, amend anyway

1) Statutory provisions are hard to interpret as contract terms – especially HITECH

2) Statutory obligations do not define details of contract compliance

· E.g. security breach notification requirements do not specify CE notice terms, procedures for response coordination, cost allocations, etc.

· Staged amendment processes

1) Implement new forms to use going forward – new and renewing contracts

2) Ensure BACs are identified and subject to management

3) Communicate SOON with key BA or CE business partners

J. New BAC Termination Rules:

Section 164.504(e)(1)(ii) of title 45, Code of Federal Regulations, shall apply to a business associate . . . in the same manner that such section applies to a covered entity, with respect to compliance with the standards in sections 164.502(e) and 164.504(e) of such title, except that in applying such section 164.504(e)(1)(ii) each reference to the business associate, with respect to a contract, shall be treated as a reference to the covered entity involved in such contract.

HITECH § 13404(b)

· 45 CFR § 164.504(e)(1)(ii): Termination of business associate contract for breach

· 45 CFR § 164.502(e), .504(e): Business associate disclosure and contract standards and specifications

K. Old BAC Termination Rule

A covered entity is not in compliance with the standards in §164.502(e) and paragraph (e) of this section, if the covered entity knew of a pattern of activity or practice of the business associate that constituted a material breach or violation of the business associate's obligation under the contract or other arrangement, unless the covered entity took reasonable steps to cure the breach or end the violation, as applicable, and, if such steps were unsuccessful: (A) Terminated the contract or arrangement, if feasible; or (B) If termination is not feasible, reported the problem to [DHHS]

45 CFR § 164.504(e)(1)(ii)

L. Interpretation of the New Termination Rule

Here’s the old rule, with “Business Associate” substituted for “Covered Entity” and vice-versa, to demonstrate how this works.

A [Business Associate] is not in compliance with the standards in §164.502(e) and paragraph (e) of this section, if the [Business Associate] knew of a pattern of activity or practice of the [Covered Entity] that constituted a material breach or violation of the [Covered Entity’s] obligation under the contract or other arrangement, unless the [Business Associate] took reasonable steps to cure the breach or end the violation, as applicable, and, if such steps were unsuccessful: (A) Terminated the contract or arrangement, if feasible; or (B) If termination is not feasible, reported the problem to [DHHS]

45 CFR § 164.504(e)(1)(ii)

· How will this work in real life? How can a CE violate a BAC? (There are several ways I can think of)

· What BAs might learn about CE violations? Should CEs include some kind of BAs in compliance programs, e.g. violation hot lines?

· What traps exist? Can e.g. a BA law firm ethically report a CE violation?

· How to draft sensible BAC terms around this? Can the same kinds of terms be used for all contracts? Maybe include CE reporting and escalation requirements prior to DHHS notice or termination?

· Note risk of new, enhanced penalties for BAs for failure to notify or terminate

M. New Rules on HIPAA Criminal/Civil Penalties

Applicable to both CEs and BAs

In the case of a business associate that violates any provision of subsection (a) or (b), the provisions of sections 1176 and 1177 of the Social Security Act (42 U.S.C. 1320d–5, 1320d–6) shall apply to the business associate with respect to such violation in the same manner as such provisions apply to a person who violates a provision of part C of title XI of such Act.

HITECH § 13404(c)

· 42 USC § 1320d-6: HIPAA criminal penalties

· 42 USC § 1320d-5: HIPAA civil penalties

N. The Old Civil Penalties Rules

1. $100 per violation of Privacy or Security Rule requirement or prohibition

2. Maximum $25,000 per calendar year per “identical” requirement or prohibition

· Example: Unencrypted transmission = $100 penalty

· 250 unencrypted transmissions = $25,000 penalty

· 10,000 unencrypted transmissions = $25,000 penalty

3. “Continuing” violations (e.g. failure to conduct risk assessment) counted at one violation per day until cured

45 CFR §§ 164.404, .406

4. Affirmative defenses: Violation due to “reasonable cause,” not “willful neglect,” and under correction. 45 CFR § 160.410

5. Penalty aggravation/mitigation factors: Nature, harm caused by violation; intentional violation vs. violation “beyond control;” compliance history; financial factors. 45 CFR § 164.408

O. The New Civil Penalties Rules

· Violation not known (despite due diligence): Remains at $100/violation to $25,000 maximum

· Violation due to “reasonable cause:” Increased to $1,000/violation to $100,000 maximum

· Violation due to “willful neglect:” Increased to $500,000/violation to $1.5 million maximum

HITECH § 13410

· All penalties currently effective

· DHHS required to publish regulations on “willful neglect” and required to impose penalties for it beginning February 17, 2011

· State attorneys general granted civil penalties jurisdiction – and attorneys fees for successful action

· Affected individuals may be awarded penalty share per regulations to be effective beginning February 17, 2012

1. New penalty regime changes the BA calculus

a) Is the contract worth the risk?

b) Can the BA provide the same (or similar) services without PHI?

c) Some organizations clearly not – RHIOs, QIOs, etc.

d) Some organizations might be able to, for some services – consulting, accounting, law, etc.

e) Should the BA increase fees to meet increased regulatory burdens and risks?

P. Effective Dates and Potential for Extension Pending Regulations?

“Unless otherwise specified:” Feb. 17, 2010. HITECH § 13423.

· BA security regulation compliance: No.

· HITECH § 113401(c) requires annual “guidance,” compliance not contingent

· BAC compliance (if amendment required): Some elements; mostly not

· HITECH § 13404(a) requires incorporation of HITECH CE privacy requirements in BAC; some require regulations to be effective

Q. New Privacy Rules - PHI: Health Plan Disclosures

1. Existing Rule: 45 CFR § 164.522

(a)(1) Standard: right of an individual to request restriction of uses and disclosures.

(i) A covered entity must permit an individual to request that the covered entity restrict:

(A) Uses or disclosures of protected health information about the individual to carry out treatment, payment, or health care operations; and

(B) Disclosures permitted under § 164.510(b).

(ii) A covered entity is not required to agree to a restriction.

(iii) A covered entity that agrees to a restriction under paragraph (a)(1)(i) of this section may not use or disclose protected health information in violation of such restriction, except that, if the individual who requested the restriction is in need of emergency treatment and the restricted protected health information is needed to provide the emergency treatment, the covered entity may use the restricted protected health information, or may disclose such information to a health care provider, to provide such treatment to the individual§13405(a)

45 CFR § 164.522

2. New Mandatory Restriction:

REQUESTED RESTRICTIONS ON CERTAIN DISCLOSURES OF HEALTH INFORMATION.—In the case that an individual requests under paragraph (a)(1)(i)(A) of section 164.522 of title 45, Code of Federal Regulations, that a covered entity restrict the disclosure of the protected health information of the individual, notwithstanding paragraph (a)(1)(ii) of such section, the covered entity must comply with the requested restriction if—

(1) except as otherwise required by law, the disclosure is to a health plan for purposes of carrying out payment or health care operations (and is not for purposes of carrying out treatment); and

(2) the protected health information pertains solely to a health care item or service for which the health care provider involved has been paid out of pocket in full.

HITECH §13405(a)

3. Questions and Implications:

· What is “out of pocket?” Cash? Check? Credit card?

· Prudent approach: Accept cash. (Why not?) Consider whether to accept checks (stop payment risk), credit cards (dispute risk)

· How are indirect and referred providers notified? Do they have independent duties to restrict information from first provider (paid in full) even if they are not?

· Review policies, procedures processes and information system controls and modify as needed to implement restrictions

· What if information is needed for plan coverage decisions? Individual informed consent?

R. New Privacy Rules: Minimum Necessary

1. Existing Rules: 45 CFR § 164.502(b)

When using or disclosing protected health information or when requesting protected health information from another covered entity, a covered entity must make reasonable efforts to limit protected health information to the minimum necessary to accomplish the intended purpose of the use, disclosure, or request.

This requirement does not apply to:

(i) Disclosures to a health care provider for treatment;

(ii) Uses or disclosures made to the individual, as permitted under paragraph (a)(1)(i) of this section or as required by paragraph (a)(2)(i) of this section;

(iii) Uses or disclosures made pursuant to an authorization under § 164.508.

(iv) Disclosures made to the Secretary in accordance with subpart C of part 160 of this subchapter;

(v) Uses or disclosures that are required by law, as described by § 164.512(a); and

(vi) Uses or disclosures that are required for compliance with applicable requirements of this subchapter.

a. Applies to requests for PHI by Covered Entities, as well as their disclosures

· For recurring types of disclosures, implement policies identifying persons or classes of persons permitted to receive, and scope of information

· For all other types of disclosures, case-by-case determination using pre-established criteria

45 CFR § 164.514(d)

2. New Rule:

a. Two phase compliance:

· Statutory Compliance: February 17, 2009 – August 17, 2010+ (18+ months)

· Regulatory Compliance: Regulation effective date forward

b. Statutory period: The following provision applies:

A covered entity shall be treated as being in compliance with section 164.502(b)(1) . . . with respect to the use, disclosure, or request of protected health information only if the covered entity limits such protected health information, to the extent practicable, to the limited data set . . . or, if needed by such entity, to the minimum necessary to accomplish the intended purpose of such use, disclosure, or request, respectively.

Subject to same exceptions as apply under regulations

HITECH § 13405(b)

3. A limited data set is protected health information that excludes the following direct identifiers of the individual or of relatives, employers, or household members of the individual:

· Name address, phone, fax, email, SSN, other ID, vehicle/device ID, URL/IP address, biometrics, photos

· Limited data set may only be used for health care operations, research, public health reporting

45 CFR § 164.514(d)(2), (3)

BUT SEE:

Agreement required. A covered entity may use or disclose a limited data set under paragraph (e)(1) of this section only if the covered entity obtains satisfactory assurance, in the form of a data use agreement that meets the requirements of this section, that the limited data set recipient will only use or disclose the protected health information for limited purposes.

45 CFR § 164.514(d)(4)

4. Questions and Implications:

· Clearly applies to payment, health care operations, most other uses and disclosures

· What is the “practicable extent” for use of a limited data set?

· When do you “need” to use a broader data set?

· Probably for almost all payment, many health care operations

· Can a Covered Entity still rely on requestor representations about “necessary” scope?

· Need to review, probably revise minimum necessary policies

· What about limited data set agreements?

· How does all this integrate into business associate contracting?

S. Accounting of Disclosures

1. Existing Rule:

Individual entitled to accounting for disclosures made for six years prior to request, except for:

· Treatment, payment, health care operations;

· To the individual;

· Incidental to permitted uses and disclosures

· Pursuant to an authorization

· Directories, care support, certain notifications

· National security

· To correctional institutions or law enforcement

· As part of a limited data set

45 CFR § 164.528(a)

2. New Requirements:

a. Grandfathered, delayed compliance:

i. Current EHR users: January 1, 2014 (may be extended by rule to 2016)

ii. EHR acquired after January 1, 2009: Date of acquisition or January 1, 2011 (may be extended by rule to 2013)

3. New rules for EHR disclosures

(1) IN GENERAL.—In applying section 164.528 of title 45, Code of Federal Regulations, in the case that a covered entity uses or maintains an electronic health record with respect to protected health information—

(A) the exception under paragraph (a)(1)(i) of such section shall not apply to disclosures through an electronic health record made by such entity of such information; and

(B) an individual shall have a right to receive an accounting of disclosures described in such paragraph of such information made by such covered entity during only the three years prior to the date on which the accounting is requested.

HITECH § 13405(c)

4. New rules for BA disclosures

In response to an request from an individual for an accounting, a covered entity shall elect to provide either an—

(A) accounting, as specified under paragraph (1), for disclosures of protected health information that are made by such covered entity and by a business associate acting on behalf of the covered entity; or

(B) accounting, as specified under paragraph (1), for disclosures that are made by such covered entity and provide a list of all business associates acting on behalf of the covered entity, including contact information for such associates (such as mailing address, phone, and email address). A business associate included on a list under subparagraph (B) shall provide an accounting of disclosures (as required under paragraph (1) for a covered entity) made by the business associate upon a request made by an individual directly to the business associate for such an accounting.

HITECH § 13405(c)

3. Questions and Implications:

a. Treatment, payment, health care operations disclosures from EHRs will be added

· Can your existing EHR track them now? Will it be able to then? Will the EHR you are going to buy be able to do it?

b. Applies whenever external entities are given access

· Disclosure means the release, transfer, provision of access to, or divulging in any other manner of information outside the entity holding the information.

· Use means . . . the sharing, employment, application, utilization, examination, or analysis of such information within an entity that maintains such information.

· So what about e.g. independent ER contractor physicians using a hospital EHR in an OHCA?

c. If you disclose addresses only, will your BAs be able to respond? Will they want to?

T. Patient Access to PHI

1. Existing Rule: 45 CFR § 164.524

An individual has a right of access to inspect and obtain a copy of protected health information about the individual in a designated record set, for as long as the protected health information is maintained in the designated record set, except for:

· Psychotherapy notes;

· Information compiled in reasonable anticipation of, or for use in, a civil, criminal, or administrative action or proceeding;

· Certain information subject to Clinical Laboratory Improvement Act (CLIA), certain information about correctional inmates, certain research or Privacy Act-protected information, certain information received under confidentiality;

· Information a licensed professional has determined could cause harm to life or physical safety

2. New Rule:

In applying section 164.524 . . . in the case that a covered entity uses or maintains an electronic health record with respect to protected health information of an individual—

(1) the individual shall have a right to obtain from such covered entity a copy of such information in an electronic format and, if the individual chooses, to direct the covered entity to transmit such copy directly to an entity or person designated by the individual, provided that any such choice is clear, conspicuous, and specific; and

(2) notwithstanding paragraph (c)(4) of such section, any fee that the covered entity may impose for providing such individual with a copy of such information (or a summary or explanation of such information) if such copy (or summary or explanation) is in an electronic form shall not be greater than the entity’s labor costs in responding to the request for the copy (or summary or explanation).

HITECH § 13405(e)

3. Questions and Implications:

· How does the right to “direct the transmission” to a designated third party relate to authorization rights and requirements?

· Can you in fact quantify your costs of response?

U. Prohibition on EHR and PHI Sales

1. Existing Rule:

Sale or transfer as part of treatment, payment, healthcare operations not prohibited as long as other conditions met – remuneration not a factor

2. New Rules:

· Rule implementation: No longer than 18 months (August 17, 2010)

· Compliance: Six month from effective date (April 17, 2011)

· Effective date is publication of final rule + 2 months

A covered entity or business associate shall not directly or indirectly receive remuneration in exchange for any protected health information of an individual unless the covered entity obtained from the individual . . . a valid authorization that includes . . . a specification of whether the protected health information can be further exchanged for remuneration by the entity receiving protected health information of that individual.

HITECH § 13405(d)

Exceptions:

· Public health activities

· Research, as long as “price charged reflects the costs of preparation and transmittal of the data for such purpose”

· Treatment of the individual

· Sale, transfer, merger, consolidation of a covered entity, where the successor will be a covered entity

· Remuneration “by a covered entity to a business associate for activities involving the exchange of protected health information that the business associate undertakes on behalf of and at the specific request of the covered entity pursuant to a business associate agreement.”

· Providing an individual with a copy of PHI

3. Questions and Implications:

What is “remuneration?”

· Stark definition: “Remuneration means any payment, discount, forgiveness of debt or other benefits made directly or indirectly, overtly, in cash or in kind.”

What is “exchange” of PHI? May covered entity transfer temporary possession to 3rd party for use?

Can you quantify research-related costs?

V. Marketing

1. Existing Rule:

Use or disclosure of PHI for marketing purposes requires authorization and notice if “direct or indirect remuneration” is paid, excluding face-to-face communications and “nominal” gifts

45 CFR § 164.508(a)(3)

“Marketing” is a communication about a product or service that encourages recipients to purchase or use the product or service, or an arrangement between a covered entity and any other entity where the covered entity discloses protected health information to the other entity, in exchange for direct or indirect remuneration, for the other entity or its affiliate to make a communication about its own product or service that encourages recipients of the communication to purchase or use that product or service.

45 CFR § 164.501

Exceptions

Health-related product or service (or payment for such) provided by, or included in a plan of benefits of, the covered entity making the communication, including communications about entities in a health care provider or health plan network or added-value health-related products or services available only to a health plan enrollee.

Treatment of the individual; or

Case management or care coordination, or to direct or recommend alternative treatments, therapies, health care providers, or settings of care.

2. New Rule:

A communication by a covered entity or business associate that is about a product or service and that encourages recipients of the communication to purchase or use the product or service shall not be considered a health care operation . . . unless the communication is made as described in subparagraph (i), (ii), or (iii) of paragraph (1) of the definition of marketing in section 164.501 of such title.

HITECH § 13406(a)(1)

Exceptions:

A communication by a covered entity or business associate that is described in subparagraph (i), (ii), or (iii) of paragraph (1) of the definition of marketing . . . shall not be considered a health care operation . . . if the covered entity receives or has received direct or indirect payment in exchange for making such communication, except where—

Communication describes only a drug or biologic that is currently being prescribed for the recipient of the communication; and

Any payment received by such covered entity in exchange for making a communication described is reasonable; and either

The communication is made by the covered entity and the covered entity first obtains an authorization from the individual; or

The communication is made by a business associate on behalf of the covered entity and the communication is consistent with the written contract between such business associate and covered entity.

“Reasonable” to be determined by regulation

3. Questions and Implications:

· Read together with HITECH § 13405(d) (EHR and PHR sales)

· Note: Applies to communications on/after February 17, 2010

· Allows e.g. prescription refill reminders, not “switch” letters suggesting different drugs

· Will the rule on “reasonable” come out by February 17, 2010?

Caveat User: Data Mining and Sneaky Services Providers

2009-07-03T12:09:00.000-07:00

According to Zero Hedge, Goldman Sachs may have been using data from activities on its news/research web portal, and possibly also its trading portal for Goldman clients, to "front run" its clients. "Front running" occurs when a brokerage firm (like Goldman) executes a trade on a stock its own behalf before executing a trade on behalf of a client for the same stock - which might, for example, result in a nice profit on a purchase for the front-runner if the following client trade is large (or otherwise influential) enough to move the stock price up, or avoid a nasty loss if the following client trade drives it down.

Front-running has been around for a while, and under some circumstances might be illegal insider trading, though that can be a hard case to make. The neat thing about Goldman's approach - and per Zero Hedge apparently that of some other comparable institutions' - is that they set up their terms of use so that users in fact consent to Goldman's use of data about their use of the web services for purposes implicitly including front running.

Terms of use, of course, are a form of contract users accept, by website actions ranging from explicit entry of user information and account setup, to simply continuing to access the website with notification of a link to the terms of use (all forms of electronic signature, generally legally binding by statute and caselaw). If you have notice of and an opportunity to read the terms of use and choose not to do so - the usual response; when did you last read a website's terms of use? - you're still bound by the information they contain and the agreements they include. (I haven't tried to find out how the Goldman website's terms of use are set up.)

The relevant provision in the Goldman terms of use states:

Monitoring by GS [Goldman Sachs]: Your use of the products and services on this Web site may be monitored by GS, and that the resultant information may be used by GS for its internal business purposes or in accordance with the rules of any applicable regulatory or self-regulatory organization.

If (1) front running is an "internal business purpose" of Goldman and (2) "in accordance with" implicitly includes the meaning "not prohibited by," website users have agreed that Goldman can use their website activity data to front-run them. If Goldman were to combine such data - which I assume could be pretty rich and detailed for a long-term user - with other information about the user, the user's employer, etc., etc., obtained from other sources - well, let's just say I think they would have a very valuable data set for their own trading decisions.

I assume some smart lawyers vetted all this for Goldman and concluded it wasn't prohibited by any applicable law - probably backed by some internal controls to avoid clear legal violations like actual insider trading by Goldman insiders who might have a fiduciary relationship to the client - but it seems to me unlikely that the average Goldman client using its website would anticipate this kind of use of its users' information, whether or not they read the terms of use. And I can readily imagine that front-running a client trade could harm the client's interests, if the broker trade ran prices up before a client purchase, or down before a client sale. But given the terms of use, they've accepted this use of their data.

I'm not sure this ends the legal inquiry; I haven't tried to figure out how the Gramm-Leach-Bliley privacy regulations or New York state privacy laws might be implicated. Again, I assume smart lawyers gave this an extensive - and expensive! - analysis, and there are internal controls intended to prevent clear violations. In any case where the user is acting on behalf of an institution these won't be implicated anyway, as they are intended to protect individual consumer privacy, not institutional interests. But I wouldn't be surprised to see NY AG Andrew Cuomo take an interest in what might have been going on under the hood, and perhaps the FTC as well. (Note: Rolling Stone reporter Matt Taibbi is on the case, so this may get some public traction.)

And one clear takeaway for me is that institutional clients of firms providing this kind of web service under this type of terms of use should seriously consider not using it. Unless the institution is using the service, and trading, on its own behalf, it probably owes some form of duty to its own clients (contractual, etc.) not to expose them to known, potentially harmful trading risks. Now that the risk of implicitly authorized front-running is known, seems to me it is something to avoid.

Caveat user. Read those terms of use!

Stop! Don't Sign that Business Associate Contract!

2009-05-26T09:21:00.001-07:00

As readers of this blog (should) know, the HITECH provisions of the stimulus bill include a very significant expansion of regulatory authority over business associates. They also include a very significant increase in penalties for HIPAA violations. The upshot of these changes is that many organizations which were not previously subject to HIPAA penalties will (relatively) soon be exposed to new, important liability risks. This changes the risk calculus for many organizations and individuals which may want to reconsider whether they are, or want to be, business associates.

Previoiusly, for many organizations and individuals in many business relationships with Covered Entities there has been little or no downside to signing a business associate contract. In many cases - I've dealt with a great many of them - Covered Entity staff handling contracts for IT, accounting, legal and various kinds of consulting services, have simply assumed that a Business Associate Contract is necessary. This assumption may or may not have been true, but was put forward without analysis, based upon a misunderstanding of the law, out of an excess of caution, or "because our lawyer requires it." (Of course, lawyers themselves have been guilty of pushing this kind of assumption.)

For the purported Business Associate in this situation the Business Associate Contract has therefore been an obstacle to the deal, but generally a minor one. The Business Associate would not be exposed to regulatory penalties for violation of the contract, and where the Business Associate Contract's terms don't include significant penalties for violation - often the case, especially when the Covered Entity has gone with a simple form - the Business Associate's risk for violation is pretty much limited to termination of the contract. As legal risks go, this isn't a big one. So, many organizations have been willing to sign off on Business Associate Contracts as a condition to closing a deal or relationship with a Covered Entity, even if they really aren't acting as a Business Associate, or could provide appropriate services without doing. so. I know of quite a few IT, legal, accounting and consulting services companies where this is the case.

If you're in that position you probably want to rethink it. As of next February 17, Business Associates will be directly regulated by Health and Human Services, directly subject to audit, and directly exposed to penalties for Security Rule violations, violations of HITECH provisions, and violations of their Business Associate Contracts. And these penalties will be potentially much greater - are a lot bigger than they used to be; think hundreds of thousands or even millions of dollars, if you violate enough provisions and do it with "willful neglect."

Now, just signing a Business Associate Contract shouldn't be enough to make you a Business Associate - though it could certainly be taken as evidence you and your trading partner intend for you to be. I would take the position that even if my client signed a document accepting Business Associate status, it really isn't unless it's done something involving Protected Health Information on behalf of a Covered Entity. But that's a legal argument, and if I have to make it my client will already be under investigation and at risk of penalties. I'd prefer not to go there, myself.

So, if you're a Business Associate, or think you might be, or never really thought about it but signed off on a contract to make a deal happen, you probably want to consider the services you provide, whether you can or want to provide them in a different way if they currently involve Protected Health Information, and maybe whether the existing compensation reflects your soon-to-increase risk.

Me? As a lawyer and sometimes Business Associate, I certainly will be looking at this.

Caselaw: When Bad Security Makes for Invalid Electronic Signatures

2009-04-13T17:02:00.000-07:00

Signatures are essential - as in, legally required - for many healthcare records, among them medical records, drug orders and prescriptions. Failure to sign violates licensing and frequently other state law provisions, and in some cases federal requirements and accreditation standards.Federal and state laws - E-SIGN and the Uniform Electronic Transactions Act (UETA, adopted in almost all states) also permit electronic signatures, and these have become a standard part of electronic health record (EHR) and electronic prescribing (e-Rx) systems.

Neither E-SIGN nor UETA specify the technologies which are acceptable as electronic signatures, but instead leave it up to the agreement of the parties. As a matter of law, then, an electrronic signature is any "electronic sound, symbol, or process attached to or logically associated with a record and executed or adopted by a person with the intent to sign the record." For example, when you download a new application you are usually confronted with several pages of license agreement and a "click to accept" button, or something similar. When you click the button, you are executing an electronic process (the results of the click) logically associated with a record (the license agreement) with intent to sign (implied by the fact that you clicked after being asked if you accept the license agreement). From a legal point of view, you have just electronically signed the license agreement.

As you can imagine, this open standard creates many opportunities for error and fraud. You could click to accept without intending to, just because you're fumble-fingered. (This is why double-click is often better solution.) Somebody else could log on to your account, or create an account using your information, and "sign" records in your name - for example, bank transfer authorizations. And so on.

The security of the process used to create an electronic signature is therefore essential to its reliability, and both E-SIGN and UETA have provisions allowing an electronic signature's validity to be proven by evidence of the "efficacy" of the security of the process. Conversely, "bad" security may be grounds to contest an electronic signature, and even have it thrown out.

This recently happened in a Kansas federal district court case, Kerr v. Dillard Store Services. The record there was an arbitration agreement potentially applicable to the plaintiff's discrimination claim against her employer.In Kerr, the employer required employees "to memorialize their arbitration agreements by executing electronic arbitration agreements
through an intranet computer system." The signature process was as follows:

To access the intranet each associate had a unique, confidential password that was created by and known only to the associate. Executing the agreement to arbitrate required the associate to (1) enter his or her social security number or associate identification number (AIN); (2) enter his or her secure password and; (3) click the “accept” option at the bottom of the arbitration agreement screen.

The execution transaction was confirmed by an email to the employee. All in all, a pretty standard electronic signature process, better than many, in my experience.

Dillard, the employer, tried to hold employee Kerr to the online arbitration agreement it claimed she had signed. However, the plaintiff claimed she never executed this process, and the burden of proof was on the employer. The court found for Kerr, reasoning that:

The problem with Dillard’s position is that it did not have adequate procedures to maintain the security of intranet passwords, to restrict authorized access to the screen which permitted electronic execution of the arbitration agreement, to determine whether electronic signatures were genuine or to determine who opened individual emails. . . . Therefore, it is not inconceivable Champlin [the store secretary] or a supervisor logged on to plaintiff’s account and executed the agreement. . . . Dillard’s has not demonstrated the efficacy of its security procedures with regard to electronic signature. . . . On this record, the Court cannot find that it is more likely than not true that plaintiff executed the electronic agreement to arbitrate.

While Kerr is not legally binding authority, as an unpublished district court decision, it does demonstrate the pitfalls of bad security for electronic signature processes as well. Healthcare organizations, which depend on signed records for essential functions associated with some of their most significant liabilities, might do well to consider how their solutions would look in court.

Red Flag Rule Board Consent and Policy

2009-04-08T10:55:00.000-07:00

If you've surfed this site, you know that one of my tenets is that we're all generally better off sharing key policies - it improves our overall knowledge base and helps set a standard of care.

In that spirit, here are some materials you might consider if your healthcare organization needs to come into compliance with the Federal Trade Commission's Red Flag Rules - which are, by the way, effective May 1, 2009. Of course, documents like these should only be adopted as part of a good data protection program, which all healthcare ogranizations should already have for HIPAA compliance purposes. I'd also strongly suggest having a look at the open source Security Incident Response Policy I posted here in 2007 - it goes well with these.

If you don't know what this is all about, a good place to start is with the FTC's own web site. And as ever, this is educational material, not legal advice. If you think you need to adopt something like this, ask your lawyer! And feel free to share these with him or her.
__________________________________________________________________________________________________________________________________________________________________________

Copyright 2009 © John R. Christiansen/Christiansen IT Law
Creative Commons Attribution 3.0 License
Distribution Permitted with Attribution Retained

CONSENT RESOLUTION FOR ADOPTION OF IDENTITY THEFT PREVENTION PROGRAM FOR [HEALTHCARE PROVIDER NAME]

The undersigned, being all of the Board of [Directors/Trustees] of [Healthcare Organization/Business Associate], a ___________ [ENTITY TYPE] (the "[ENTITY"), hereby adopt and consent to the adoption of the following resolutions:

A. The Board has been advised by ENTITY’s [General Counsel/Legal Department/Law Firm], its legal counsel, with respect to the Federal Trade Commission’s Identity Theft Prevention Red Flag Rules, as codified at 16 CFR 681.2 (“Red Flag Rules”).

B. The Board has been further advised by [General Counsel/Legal Department/Law Firm] that [s/he/it] has determined, upon consultation with ENTITY’s [Chief Financial Officer/Chief Information Officer/Compliance Officer/Billing Department Head/Medical Records Department Head/Consultant/other relevant parties], that ENTITY is a “Creditor” and maintains “Covered Accounts” within the meaning of the Red Flag Rules. [General Counsel/Legal Department/Law Firm] has therefore determined that ENTITY is required to comply with the Red Flag Rules.

C. The Board has been further advised by ENTITY’s [Chief Information Security Officer/Compliance Officer/Security Consultant] that [s/he] has conducted an assessment of identity theft risks associated with ENTITY’s Covered Accounts, and determined that there are vulnerabilities which may present potential financial, operational, compliance, reputational or litigation risks to ENTITY, as well as financial, reputational or patient safety risks to ENTITY’s patients.

D. In order to comply with the Red Flag Rules and address identity theft risks, [General Counsel/Legal Department/Law Firm] and [Chief Information Security Officer/Compliance Officer/Security Consultant] have recommended to the Board that ENTITY adopt an Identity Theft Prevention Program. The [Chief Information Security Officer/Compliance Officer/Security Consultant] has further recommended that the Identity Theft Prevention Program be integrated with ENTITY’s existing [Information Security/Compliance] Program, due to the close relationship between identity theft and prevention and the information protection and compliance goals of the latter program, and in order to implement the Identity Theft Prevention Program more efficiently.

Based upon these findings and recommendations, the Board has resolved as follows:

RESOLVED, that [Chief Information Security Officer/Compliance Officer/Security Consultant], in consultation with [General Counsel/Legal Department/Law Firm] and [Chief Financial Officer/Chief Information Officer/Compliance Officer/Billing Department Head/Medical Records Department Head/Consultant/other relevant parties], is authorized and directed to develop and implement an Identity Theft Prevention Program, as part of ENTITY’s [Information Security/Compliance] Program.

RESOLVED, that [Chief Information Security Officer/Compliance Officer/Security Consultant] and [General Counsel/Legal Department/Law Firm] shall be responsible for updating and revision of the Identity Theft Prevention Program to address changes in applicable law, changes in ENTITY’s operations or systems affecting identity theft risks, identity theft or security incidents indicating new or previously unidentified risks, and other factors affecting the effectiveness of the Identity Theft Prevention Program, in consultation with the [Chief Financial Officer/Chief Information Officer/Compliance Officer/Billing Department Head/Medical Records Department Head/Consultant/other relevant parties], as appropriate.

RESOLVED, that the [Chief Information Security Officer/Compliance Officer/Security Consultant] and [General Counsel/Legal Department/Law Firm] shall report to the Board when the Identity Theft Prevention Program has been implemented, at the next regular meeting of the Board after the effective date of such implementation, and in any case at the next regular meeting of the Board after [TIME PERIOD]. Following implementation, the [Chief Information Security Officer/Compliance Officer/Security Consultant] shall include a report on the Identity Theft Prevention Program along with [his/her] regular reports to the Board on the [Information Security/Compliance] Program.

RESOLVED, that the Board hereby authorizes the [Chief Information Security Officer/Compliance Officer/Security Consultant] to spend up to ______________ dollars for development and implementation of the Identity Theft Prevention Program. Following implementation, the Identity Theft Prevention Program shall be included as an element of the annual [Information Security/Compliance] Program budget, according to ENTITY’s usual procedures.
_____________________________________________________________________________________

Copyright 2009 © John R. Christiansen/Christiansen IT Law
Creative Commons Attribution 3.0 License
Distribution Permitted with Attribution Retained

ENTITY NAME Identity Theft Prevention Policy

Information Security Policy No. 5.4

Objective of this Policy: The objective of this Policy is to provide assurance that neither ENTITY’s patients nor ENTITY are harmed by ENTITY’s receipt, creation, use, processing or disclosure of false or inaccurate personal information, including but not limited to protected health information as defined by Health Insurance Portability and Accountability Act of 1996 and its implementing regulations ("HIPAA").

This Policy is intended to help accomplish these objectives by providing guidance to ENTITY’s Workforce and Contractors, so that they will be able to:

Recognize events or circumstances which may indicate that that identity theft is occurring or has occurred;

Know how to report possible identity theft;

Know who is responsible for and authorized to respond to possible identity theft; and

Know the procedures which should be followed in responding to possible identity theft.

Recognizing Identity Theft: All members of ENTITY’s Workforce and Contractors are responsible for knowing how to identify possible identity theft affecting an ENTITY patient.

Identity theft is the inappropriate or unauthorized misrepresentation of personal information for the purpose of obtaining access to property or services. Identity theft is often committed in order to obtain credit to purchase consumer goods, but may also be committed to obtain medical care, drugs and supplies, or payment for care, services or supplies. Identity theft may result in false or inaccurate information becoming included in medical and billing records, and other patient records, and provided to third parties who may rely upon it in making diagnostic, treatment, credit and other important decisions.

The following are examples of facts and circumstances which may indicate identity theft. These are only examples, and many other facts or circumstances may be identity theft indicators.

Identification documents which appear to have been altered or forged.

The patient cannot provide documentation of identifying information, such as a health insurance card.

The patient provides inconsistent identifying information, such as a Social Security Number in a range which does not correlate with the reported birth date.

The Social Security Number or other identification or account number provided is already identified with another patient.

The patient’s medical history, physical appearance or diagnosis is inconsistent with the same information in the medical records.

A report by the patient or insurance company that coverage for the provision of legitimate products or services has been denied because insurance benefits have been depleted or a lifetime cap has been reached, which is inconsistent with known coverage.

A patient inquires or complains about inappropriate billing or notices, such as:

A bill for another individual, for services the patient denies receiving, or from a health care provider the patient denies receiving services from.

An explanation of benefits or other insurance notification for products or services the patient denies receiving.

A collection notice or credit report for a debt for products or services the patient denies receiving, or from a health care provider the patient denies receiving services from.

The repeated return of mail sent to the patient’s address of record as undeliverable, while products or services continue to be provided to the patient.

Notification by the patient, an individual claiming to be a victim of identity theft, any law enforcement agency, or any other person that an account or record has been opened or created fraudulently by ENTITY.

The receipt of identification information associated with known fraudulent activity.

Reporting and Responding to Potential Identity Theft: All members of the Workforce and Contractors are required to report possible or suspected identity theft when they obtain information or observe activities or records which reasonably seem to indicate its occurrence.The [Chief Information Security Officer/Compliance Officer/Security Consultant] shall provide forms for such reports. Reports may also be made to the [COMPLIANCE HOTLINE].

Each [BUSINESS UNIT] shall establish written procedures for reporting and initial investigation of potential identity theft, including identification of accountable investigative staff, expected investigative activities, and expected initial investigation response times. The results of each initial investigation shall be documented in writing. Reports and investigation results documentation shall be retained by the [BUSINESS UNIT] for one year. The [Legal Department/Chief Information Security Officer/Compliance Officer] shall review such documentation annually for internal reporting purposes.

In the event an initial investigation determines that there is a reasonable possibility of identity theft, the [BUSINESS UNIT HEAD] shall promptly report that finding to the [Legal Department/Chief Information Security Officer/Compliance Officer]. The [Legal Department/>Chief Information Security Officer/Compliance Officer] shall document any such report and promptly initiate further investigative action. The results of any such investigation shall be documented in writing and retained by [Legal Department/>Chief Information Security Officer/Compliance Officer]for at least one year, and such reports shall be reviewed annually for internal reporting purposes.

Any identity theft confirmed by the Legal Department/Chief Information Security Officer/Compliance Officer] shall be treated as a Security Incident, subject to the Security Incident Response Policy.
WHERE ANY INDIVIDUAL HAS REASON TO BELIEVE THAT POSSIBLE IDENTITY THEFT ACTIVITY HAS RESULTED IN THE RECEIPT, CREATION OR DISCLOSURE OF FALSE OR INACCURATE INFORMATION WHICH MAY BE USED IN CARE OR TREATMENT DECISIONS POTENTIALLY AFFECTING PATIENT HEALTH OR SAFETY, THE POTENTIAL IDENTITY THEFT SHALL BE REPORTED IMMEDIATELY TO THE [APPROPRIATE OFFICER].

I'm now blogging at HITRUST Central

2009-03-02T14:42:00.000-08:00

You probably noticed I haven't been keeping this blog up very well. Fact is, I was hoping for some more conversation! So, I've decided to join the blogging at HITRUST Central, a community website maintained by the Health Information Trust Alliance - click the link and look for my blog, if you want.

I will likely post every now and again here, on topics not appropriate for HITRUST Central.

Thanks!

How Do You Amend Your Terms of Use? Hint: Don't Hide the Ball.

2008-04-28T19:51:00.000-07:00

I've just caught up to a 9th Circuit case on the adequacy of notification of changes to website terms of use, for purposes of binding users. I'm a bit embarrassed as it's a few months old, but in my defense the holding is rather buried and its implications probably weren't clear to the folks doing the indexing.

The case, *Douglas v. U.S. District Court*, 495 F.3d 1062 (9th Cir. 2007), involved a change to terms of use for an AOL subsidiary providing long-distance telephone services. The subsidiary was acquired by Talk America, which changed the existing terms of use to add a number of new clauses, including a new arbitration provision and a waiver of the right to class actions. The plaintiff, a California resident, filed a class action on a number of claims arising from the change in terms. The defendant moved to compel arbitration based on the new arbitration provision. The District Court granted arbitration and the plaintiff appealed.

On appeal the 9th Circuit held the arbitration clause was not enforceable, as a matter of:

(1) General contract law, because Talk American did not provide adequate notice of the changes to the plaintiff: "Nor would a party know when to check the website for possible changes to the contract terms without being notified that the contract has been changed and how. Douglas would have had to check the contract every day for possible changes. Without notice, an examination would be fairly cumbersome, as Douglas would have had to compare every word of the posted contract with his existing contract in order to detect whether it had changed."

(2) California law, under which "a contract can be procedurally unconscionable [i.e., unenforceable] if service provider has overwhelming bargaining power and presents a "take-it-or-leave-it" contract to a customer — even if the customer has a meaningful choice as to service providers."

I won't say that this is necessarily a dramatic change to existing law, because "existing law" in this area hasn't exactly been clear. The case doesn't analyze existing caselaw on "clickwrap" or "shrinkwrap" agreements, although this is clearly what it deals with. It doesn't discuss the possible distinctions between consumer transactions, which apparently were at stake here, and B2B or other sophisticated party transactions.

What I would say is that this is a caution-and-warning for management of terms of use, privacy notices, website licensing and the like: If you don't push out amendments, they may not be binding in court. Have a look at how you manage these changes. (What, you don't already?)

I would also say that this indicates the importance of jurisdictional issues: Don't assume there are "general principles" which apply to your online agreements (whether you call them terms of use, privacy notices, licenses or whatever); assume rather that the laws of the most Draconian jurisdiction where you do business apply. (Again, you don't")

And finally, beware of court opinions coming out of left field. This was an important decision, which evidently hadn't been adequately briefed on electronic commerce issues, and bubbled up out of arbitration caselaw. Those who like sausages, perhaps, shouldn't watch the laws being made . . .

And my guess is that due to the *apparently* narrow nature of the holding (re arbitration) this isn't a candidate for S.Ct. review.

I Seem to be a Spime: Why Nobody Wants EHRs and PHRs

2008-04-21T16:33:00.000-07:00

How's that for an obscure subject line? Please bear with me; I will explain. And if you, like me, have been trying to figure out how to implement electronic health records (EHRs) and personal health record (PHRs) in the face of seemingly unrelenting foot-dragging and friction, you might even find this worth reading.

First off, we need to distinguish EHRs and PHRs from EMRs (electronic medical records). While there is some confusion and overlap is use of these terms, in practical terms an EMR is usually the electronic equivalent of the traditional paper medical record. An EMR, especially in larger organizations, is not a simple electronic "flat file" transformation of the paper record into something like a Word or Excel document, but is a system made up of various applications and databases which store and process patient data.

More to the point, however it is structured an EMR performs well-known, well established and valued functions for a specific entity. Like a paper medical record, an EMR is created, owned, and maintained by a specific healthcare provider (hospital, clinic, physician), and serves the mission-critical business purposes of that provider (patient care support, legal risk management, etc.). The provider does have legal obligations to provide medical record information to patients and other treating providers, but the core concept is that the EMR provides necessary business and compliance support to the entity which pays for it and assumes the burdens of maintaining it.

Terminology in this area is fluid and sometimes the same kind of system, under the same management and serving the same purposes, is called an EHR. This seems to be the core concept in the Stark and antikickback exceptions, for example, though that's not altogether clear. So sometimes an EHR is an EMR. But not always.

EHRs are also (conceptually and some time in the future, if not typically in current practice) something more like a community resource for healthcare organizations and patients, including medical record and other relevant information on patients from all providers (and other healthcare organizations), up to and ideally including a lifelong record of all diagnoses and care from all providers. Sometimes this kind of EHR is said to be owned by the patient, and in this direction the EHR sometimes becomes indistinguishable from the PHR.

The necessary technologies to implement this kind of system already exist (albeit with many, many issues to be resolved on matters such as interoperation, etc., etc.), and the concept is pretty clear: Each of us will some day have a comprehensive, searchable, online electronic record which documents our health history and status. Our physical presence will be complemented by and linked to an online information service, which is used to guide highly customized decisions about our care - the kinds of products and services we might need or benefit from, in a medical sense.

In other words, we'll all become spimes.

Science fiction writer-turned-design critic Bruce Sterling (one of the few people who has a job I want more than the one I have) coined the term "spime" to mean a sort of hybrid manufactured/network object: "[Spimes] are precisely located in space and time. They have histories. They are recorded, tracked, inventoried, and always associated with a story. . . . Spimes have identities, they are protagonists of a documented process. . . . They are searchable, like Google. You can think of spimes as being auto-Googling objects."

I'm not sure what, exactly, auto-Googling might be, but here's Sterling's scenario for how you might encounter a spime, which should give some sense of how the concept applies to EHRs and PHRs:

"You buy a spime with a credit card. Your account info is embedded in the transaction, including a special email address set up for your spimes. After the purchase, a link is sent to you with customer support, relevant product data, history of ownership, geographies, manufacturing origins, ingredients, recipes for customization, and bluebook value. The spime is able to update its data in your database (via radio-frequency ID), to inform you of required service calls, with appropriate links to service centers. . . . "

This same notion can be extended from manufactured objects to biological entities with the greatest of ease. Consider what an ideal EHR/PHR could do and include: Demographic information, details of your physical and mental conditions, medical history, identification and contact information for your healthcare providers and health care payors, details of your available health benefits (and credit history?) - all updated to provide alerts for "service calls" you should make to physicians and pharmacies, accompanied by useful "customization" information about treatments for your specific conditions. Add some family history, maybe some DNA analysis. For some subjects maybe you even do add physical location information, via embedded RFIDs for institutionalized or incompetent patients, prisoners, military personnel, or in hospital patient wristbands, etc. . . .

With the implementation of this kind of system you will be recorded, tracked, inventoried and associated with the story of your own health history - you are the protagonist of the documented processes of your interactions with all the various aspects of the health system you've encountered in your life. So as far as I can tell this would make you, well, a biological spime - a hybrid biological/network object.

Sounds scary and pretty complex, no? Yes, actually, and the complexity may be what keeps it from getting too scary too fast.

Sterling knows that even manufactured spimes take a lot of work, and distinguishes between those who produce spimes (manufacture the objects and create the network space for them) and spime "wranglers," a "class of people willing to hassle with spimes." Spime wranglers have an interesting relationship to spime-producers: They do a lot of the customization work for them, and provide them with feedback about how useful and valuable the spime is."

In the PHR world, then, you might consider Microsoft and Google as spime producers: They enable the network spaces necessary for information to be loaded and maintained, and for interaction with the applications needed for data processing for customized services, etc. But (as Sterling foresees), loading and maintaining this network resource is going to be a *lot* of work. Who's going to wrangle your PHR?

Do I wrangle my own PHR as part of me-as-a-spime? This might be an empowering opportunity for those with the time, training, experience and skills needed to successfully manage their PHR, but it will be an enormous pain in the hind end for those who don't. Most people these days take their health care as something produced by others, over which they have little control, and which they can only choose to consume (or not). (Interestingly, in the perspective Sterling brings, this puts most of us a couple of historical steps back from being able to manage ourselves as spimes.)

Does my physician wrangle my EHR as part of me-as-a-spime? I'm not sure why she would. She's already overburdened by running her practice and providing care to my physical self. As to having staff do it, they're busy too, and she doesn't really have an incentive to pay for and assume the burden of creating a network object which is a community resource: Her practice gets a small part of the benefit in return for assuming all the costs? While it may be true that everyone, including her practice, will be better off once the entire community resource (i.e., EHRs for everyone) is built, until that happens those who do assume the spime-wrangling burden are at a competitive disadvantage compared to those who don't.

The same argument seems to apply to hospitals, health systems, health plans and so on: Each possible candidate is at a competitive disadvantage if it assumes the very real burdens of EHR-wrangling. Unlike the EMR, there's no mission-critical purpose served for any given organization by having this kind of community/network resource available. It may enable the organization to provide better care and maybe even get it some savings, some day, but as long as the EHR/PHR is not the market norm, no market participant is disadvantaged by its absence.

What I take away from all is that until we reach a point at which some critical mass of EHR/PHR spimes is established (and positive network effects take over), somebody is going to have to compensate the spime wranglers. This, of course, is what physicians say whenever the topic of EHR implementation is brought up - and the point is, they're not wrong. Implementing an EMR for their own purposes is a lot of work; implementing and maintaining an EHR as a common resource for the general good is even more, and for less relative benefit (for them). And while some consumers might really like wrangling their own spimes, or find it genuinely beneficial (e.g. for managing chronic conditions), most probably won't find it as rewarding as doing many of the other things you can do on the Internet.

Until we can find a way to make the incentives for EHR/PHR wrangling outweigh the burdens, I'm not sure how the ideal EHR/PHR system gets built (using only market factors). EMRs, sure; EHRs which are essentially EMRs, sure. EHRs/PHRs which are a community resource through which each one of us is a biological spime, I'm not so sure.

Sterling's talk about spimes is at: http://www.boingboing.net/images/blobjects.htm

Bonus aging hippie/geek points if you recognized the source of the subject line as Buckminster Fuller!

Data Havens and UFO Hacking

2007-04-28T15:27:00.000-07:00

This probably dates me but is too good to pass up. The once-upon-a-time data haven of Sealand has offered political asylum to the guy who hacked into NASA and DoD computers in search of UFO information.

From Personal Computer World (UK)

North Sea 'state' offers McKinnon asylum

Sealand may not be enough to save 'most prolific hacker' from extradition
Emil Larsen, Personal Computer World 26 Apr 2007

Gary Mckinnon, who faces extradition to the US for allegedly hacking into military computers, has been offered asylum by the self-styled breakaway state of Sealand, it was claimed at the Infosec security conference today.

The "state", a World War II fort known as Roughs Tower in the North Sea just north of the Thames, was declared an independent principality in 1967 by a former major called Paddy Roy Bates. He dubbed himself Prince Roy.

Mckinnon sat on a ‘hackers panel’ at Infosec to debate new changes to the Computer Misuse Act. The claim about Sealand was made by one of his fellow panellists, a "security analyst" identified only as Mark.

Mckinnon, described by American prosecuters as the most prolific hacker of all time, spoke only twice, first to introduce himself and then when asked if companies often overstate the value of damage done by hackers.

Mckinnon said they did. He added the US could only have extradited him from the UK, if it could show his the offence was "worth a year in prison in both countries".

He added that to merit that sentence the damage had to amount to $5,000 dollars. The damage he was accused of causing came to exactly that so US military were "obviously not shopping in PC World".

McKinnon's lawyers have said they plan an appeal to the House of Lords against Home Secretary John Reid's granting of a US request to extradite McKinnon.

Newbie Lawyers as Enablers of Bad Security

2007-04-03T12:13:00.000-07:00

This post is a bit of a rant so please bear with.

I'm currently neck-deep in a variety of projects and a couple of presentations about security for electronic health records. This happens to be a field I've worked in since the early 1990s - though we didn't generally call them "electronic health records" then - so I've seen quite a few initiatives, applications and companies come and go.

The current round of activity is seeing a number of newbie lawyers advising and opining on EHR issues - and there's nothing wrong with that; it's a great field of practice and we all have to start somewhere - but as far as I can tell some of these folks either haven't bothered to research security issues and the history of the field, or don't even know there's something they are missing.

Twice in the last few days I've read a lawyer's assurance that EHR issues are all copacetic because, by golly, the records are going to be password protected. One seemed quite pleased to note this, almost breathless with enthusiasm (if you can be breathless in print).

I've got nothing against passwords - some of my favorite files are password-protected - but what these folks appear not to understand is that by telling me this, you have told me nothing very important. Not as important, for example, as if they had noted that there wasn't password protection - then I would either be interested to know what alternative means of authentication were proposed, or stunned to find out that even minimal authentication was foregone. But passwords are so pervasive and basic (a "due care" safeguard, to use Donn Parker's term) that this is not significant information.

What is meaningful is the suite of security safeguards, including but not at all limited to authentication, used to protect a given EHR. And this is something we've known for quite some time - even lawyers have known it. Or I guess to be more accurate: some lawyers have known it. The ABA's digital signatures/PKI initiatives developed a solid, if smallish cadre of lawyers who are pretty good (some very good) on information security issues, and there have been other groups, projects, and activities which have trained lawyers to deal with information security issues; there are some pretty good law review articles and a few treatises out there. And of course, the HIPAA Security Rule gives a pretty good list of security areas which should be addressed in any EHR. And that's just the resources available without consulting information security professionals and infosec publications, which any lawyer working in this field should do routinely.

One reason this makes me peevish is that this seems to me a tremendous waste of good intellectual capital. We've learned a lot already, some of it very much the hard way - wouldn't it be a good idea to avoid known pitfalls? Especially if you're representing clients who are going to be putting highly sensitive, personal medical information into networked applications with the deliberate goal of enabling remote access?

Which leads to the main reason I'm feeling peevish: I often see this kind of advice used to validate bad security decisions. There's almost always a good argument for bad security: It's cheaper than good security. Look what happened with PCASSO - very good EHR security, patients liked it (they felt secure) but doctors found it burdensome. So what do they want to use? Passwords. Preferably their dog's name. (I got that again a couple of weeks ago - mentioned that as an example of bad security in talking to a doc, whose immediate blush-and-cough I took as an admission of guilt, which he confirmed.) And a lawyer who doesn't know better will validate this choice.

Do I think passwords are never good enough authentication? Certainly not - that's not the point of this post.

The point is that lawyers play a significant role in risk identification and management decisions, such as those affecting EHR implementation, and it behooves us to either get up to speed on the issues before giving advice, or admit we aren't up to it and not fake it. (Sidebar: "Behoove" is a great word which doesn't get nearly enough use.)

If passwords provide sufficiently low-risk authentication, given the client's risk tolerance and in the context of the client's business processes and information systems, then it is the client's decision that it is an acceptable implementation. But this decision should be made in consultation with a lawyer, and if that lawyer doesn't know the issues - and perhaps doesn't even know that s/he doesn't know - that decision is badly grounded. A newbie lawyer may well wind up enabling a bad security decision.

I happen to think that EHRs and health information networking are in general a good idea and will ultimately be very beneficial. But we need to recognize that we are building an untested infrastructure for the storage and management of vast quantities of the most sensitive personal information, with opportunities for privacy, health and safety threats we can't yet forecast accurately. We should make security decisions for this infrastructure with caution, an appreciation for the limits of our knowledge and expertise, and a willingness to learn and figure out new tricks.

Rant over!

Self-Help on the Internet: Is the Best Defense Really a Good Offense?

2007-03-25T15:23:00.000-07:00

What are you willing to do to defend your network against hackers, zombies and Fourth Generation information warriors? What are you willing to do to defend the Internet from them? Are you going to hunker down and harden your defenses, or are you willing to defend yourself by “hacking back” and shutting the attackers down?

You may not have considered these questions; they are not usually brought up as part of information security strategy or tactical development, or in IT planning in general. But they are fundamental questions, and the answers we give may determine how well we are able to manage and maintain the information systems we have built and become increasingly dependent upon.

The Fundamental Problem of Network Insecurity.

The Internet was not designed for security, and neither were most computers. This was a feature, not a bug; security slows down communications and interferes with convenience. There was no real demand for security until the vulnerabilities of these systems became painfully obvious, which is a recent development for most people; and many still don’t seem to get it. As a result the Internet, including all the networks which connect to and constitute it, are exposed to attacks from vast swaths of unsecured systems.

The Internet is also not something you can effectively police. Most law enforcement agencies don’t have the time, resources or expertise to investigate or prosecute Internet-based crimes. And many attacks cross jurisdictional boundaries, making legal action difficult and often impossible. Even when legal action is possible, it is usually too late: the harm has been done. For the bad guys this too is a feature rather than a bug.

This means that networks connected to the Internet – ultimately the Internet itself – are subject to degradation by hostile or malicious activities. The Internet is a common good – an amazing asset shared by a community whose membership is limited only by access to and ability to use a networked computer – and as such is subject to partisan or minority abuses which undermine or conceivably could even ruin it for everyone.

So how do we defend this amazing resource? If we can’t call in law enforcement, what about self-help? Should we form some kind of Internet militia? Maybe some vigilante action? Before you decide, consider the following cautionary tale.

Shooting from the Hip.

Warbucks Financial is a boutique financial services firm whose founder, “Sonny” Warbucks, is a well-known entrepreneur with controversial views and a choleric personality. Warbucks uses the latest information technologies for trading and employs Francis X. Hackerman as its Chief Information Officer. Hackerman made his reputation as a notorious hacker, and while officially reformed he considers himself a highly skilled “hired gun.”

The University of Hard Knocks has a large, complex network serving thousands of users. Security is hard to maintain, since security measures are resisted and/or ignored by many users. One of the groups of resisters is the Script Kiddiez for Justice, which has taken a very public dislike to Warbucks.

Shortly before closing on a Friday afternoon Warbucks begins experiencing a distributed denial of service (DDOS) attack which threatens to shut down its ability to execute trades. This is a crucial time of the week and Warbucks’ clients may face serious losses if their trades are delayed.

Hackerman tries to deal with the attack by hardening the Warbucks network, but this slows trading even further. He identifies the Hard Knocks network as a source of the attack and assumes the Script Kiddiez are behind it. Hackerman tries to contact Hard Knocks Information Services to get them to intervene, but all he gets is voice mail.

A red-faced, bellowing Sonny appears in Hackerman’s doorway, demanding that he “fix it and quick.” Hackerman decides to try to eliminate the attack – and Sonny’s disturbing presence - by shutting down some or all of the Hard Knocks network.
Hackerman is a former student at Hard Knocks and knows a number of vulnerabilities in its network. He quickly modifies a publicly available worm and releases it into the Hard Knocks network, and soon hosts on the network begin shutting down.

Meanwhile, Eunice Victim has just been admitted to the Hapless Hospital emergency room to have a boil lanced. Hapless is a teaching hospital which is part of Hard Knocks and runs its information systems on the Hard Knocks network. These systems include a computerized physician order entry (CPOE) application linked to its electronic medical records system (EMR).

Victim’s EMR indicates she has an allergy to amoxicillin. However, as her treating physician, Dr. Ohno, was ordering antibiotics Hackerman’s worm crashed the CPOE. Ohno then asked Victim her about possible antibiotic allergies, but unfortunately Victim misunderstood and indicated she had none. When Victim received the amoxicillin Ohno ordered she went into anaphalytic shock and died.

The attack on Warbucks continued, and subsequent investigations indicated it most likely originated somewhere in the Middle East as part of a broad series of attacks on financial institution networks probably intended to harm U.S. financial markets.
The Hard Knocks incident response team traced the worm back to Warbucks Financial. Victim’s estate sued Ohno and Hapless for negligence in her death, and they in turn cross-claimed against Warbucks Financial, Sonny and Hackerman. Hapless, Hard Knocks and Victim’s family all demanded that criminal charges be brought against Hackerman, Sonny and Warbucks Financial.

Categories of Network Self-Help.

The above scenario would make a great bar exam question, and I challenge readers to identify all the legal issues it presents. The immediate point, however, is that the risks posed by network self-defense actions increase dramatically in proportion to the degree that they affect systems outside the network’s legal and operational perimeter.

This is because within a network perimeter the network operator has (1) sufficient information, at least in principle, to identify and avoid unintended harmful consequences of security measures, and (2) the legal authority to implement any security measures it wants, subject to its own policy limitations. Conversely, in others’ networks a party generally has limited information, and the legal right to act only to the extent they give permission.

Given these constraints Internet self-help can be categorized roughly as follows:

• Baseline: At the most basic level, within its network perimeter a party can implement whatever security measures it considers appropriate. It may also have a legal duty to do so, if the failure to implement security measures exposes others to avoidable risks (e.g., unsecured hosts used to launch DDOS attacks on third parties).

• Investigative: Moving out from its own network perimeter, a party has the legal right to conduct limited investigative activities to identify potential attack sources, to the extent these activities are not harmful and are consistent with ordinary Internet functions (e.g., pinging a host). This may be useful for identification of a party who has the authority and ability to shut down attack activity, at least sometimes.

• Cooperative: Two or more parties may take joint defensive actions within their networks on an ad hoc basis in response to an attack, or agree to a “mutual defense pact” which defines the terms of joint responses within their networks. This may be particularly useful where two or more parties are regular business partners.

• Adversarial: One or more parties may take action affecting resources in a network owned by another, without that party’s permission. This action could violate laws such as the federal Computer Fraud and Abuse Act and state computer trespass laws – not to mention issues if the network turns out to be a national security system or located in another country. There are self-defense theories which might work in a legal action, but they have not been tested in court.

Conclusion.

The Internet isn’t quite the Wild West, but it’s no well-regulated commonwealth, either. In this environment it’s up to the individual organization to defend its own network. This, of course, not only helps the organization, but helps preserve the Internet by preventing network misuse. There is also a valuable role for cooperative efforts, such as information sharing and even joint incident and attack responses. Something like a “well-regulated militia,” then, might be worth exploring, at least in the context of a mutual defense pact.

Vigilante action, on the other hand, is strictly at your own risk. There may be circumstances when adversarial self-help is really needed – certainly there may be circumstances where that seems to be the case. But before undertaking such action you had better be very sure of yourself – you may very well wind up having to explain it in court.

Organizational Governance and Risk Acceptance

2007-03-14T07:27:00.000-07:00

Managing HIPAA Security Compliance:Organizational Governance and Risk Acceptance

One of the fundamental but sometimes overlooked questions in HIPAA Security Rule compliance is, who decides how much residual security risk the organization will accept? The level at which this decision is made can have important consequences not just for the acceptance of HIPAA security compliance measures within the organization, but for the cost-effectiveness of the safeguards selected for compliance and the organization’s ability to defend itself and its officers against civil penalties or criminal charges if its personnel do violate HIPAA’s information protection requirements.

The level at which security risk acceptance authority is vested depends on how the issue is perceived. Senior executives, auditors and legal counsel and board members may not understand or be comfortable with information security issues, and may perceive them as matters of technical implementation. They may therefore explicitly, or perhaps more often implicitly and by default, delegate decisions about such issues to security professionals they consider more qualified to deal with such problems. Some security professionals may be quite willing to accept such delegation, not recognizing that it may be inappropriate – maybe not really recognizing that it is occurring – perhaps even seeing it as a positive enhancement of their power and authority.

Risk Management: In the Eye of the Beholder?

The inappropriate delegation of risk acceptance authority may be particularly likely to occur under the HIPAA Security Rule because of the way it uses the term “risk management.” The Rule specifies that compliance decisions – the selection of safeguards which are “reasonable and appropriate” for addressing risks under the standards and specifications set forth in the rule – are to be made using a risk assessment-based risk management process. “Risk management,” however, can mean different things to different professions, creating a real possibility of confusion and a dysfunctional approach to compliance.

For organizational governance purposes, “risk management” generally means

. . . a policy process wherein alternative strategies for dealing with risks are weighed and decisions about acceptable risks are made. . . . In the end, an acceptable level of risk is determined and a strategy for achieving that level of risk is adopted. Cost-benefit calculations, assessments of risk tolerance, and quantification of preferences are often involved in this decision-making process.

Confusingly, however, the HIPAA Security Rule and many (by no means all) security professionals give the term “risk management” a much more limited meaning, as the implementation of “security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level.” Security “risk management” under the latter definition is therefore equivalent to risk reduction at the organizational level – a process which depends upon the prior determination of the acceptable risk level to be achieved by the reduction.

Information technology security risks cannot as a practical matter be reduced to zero, nor does the HIPAA Security Rule require “zero risk tolerance.” The rule does require that healthcare organizations “take steps, to the best of [their abilities,] to protect [protected health information in electronic form].” This requirement is based on an interpretation that in the legislation Congress intended to set “an exceptionally high goal for the security of electronic protected health information” but “did not mean providing protection, no matter how expensive.” Covered Entities are therefore permitted to use a “flexible approach” to security measure implementation which permits them to implement “any” measures which are “reasonable and appropriate,” taking organizational circumstances and factors including costs into account.

At the end of this process residual risks will have to be accepted by some party on behalf of an organization. Compliance with the rule is itself an organizational obligation, and the organization is exposed to civil and potentially even criminal penalties in the event of a compliance failure. Since acceptance of residual risks necessarily means the acceptance of some degree of exposure to potential penalties – even if the organization makes its compliance decisions properly and in good faith there is a possibility that enforcement authorities will disagree with them – this decision should only be made as a matter of organizational policy.

Fiduciary Obligations and Security Risk Acceptance.

It is a truism that the officers and directors of an organization have fiduciary obligations to provide oversight to ensure it complies with regulatory obligations. What is perhaps less well understood is that a failure to exercise such oversight could itself be a factor exposing an organization to avoidable legal penalties.

HIPAA provides not only for a regulatory regime, but for criminal penalties for organizations which obtain or disclose protected health information (“PHI”) in violation of the statute or the regulations. (Individuals can be subject to criminal penalties too, but this article is concerned with organizations.) Healthcare organizations obtain and disclose PHI constantly – it’s a necessary part of most operations – which means that a failure to comply with the HIPAA Security Rule in the course of operations involving PHI is a per se criminal violation. For example, the rule presumes that all personnel will receive appropriate security training, and requires that all information system users be assigned unique user names or other identifiers. Any receipt or disclosure of PHI by an untrained user, or by a user who is allowed to log-in under another user’s identifier, could be considered a criminal HIPAA violation by the organization.

This may seem a somewhat extreme reading of the statute, but it is the result of its literal interpretation. Whether charges are ever brought against a healthcare organization which fails to comply with the HIPAA Security Rule will therefore generally be a function of whether the failure has been brought to the attention of the U.S. Department of Justice (which has federal criminal jurisdiction), and if so whether the U.S. Attorney elects to bring charges. While it is to be hoped that prosecutors will exercise their discretion cautiously in such cases, hope is not a prudent strategy for legal compliance.

A better strategy, and one which is recognized in federal criminal sentencing and prosecution decisions against organizations, is to implement a compliance program including organizational policies and board and executive-level oversight. The existence and good faith, reasonable management of such a program is a very material factor relied on by the U.S. Department of Justice in deciding against organizational prosecution when one of its employees or agents breaks the law, and in minimizing penalties if the organization is prosecuted.

More than that, a compliance program would constitute the kind of policy-level security risk management process necessary to determine acceptable levels of risk at the organizational level under the HIPAA Security Rule, which in turn would guide decisions about the reasonable and appropriate safeguards which the organization should implement. By instituting this process the organization would be able to ensure that “reasonable and appropriate” decisions are made, in reliance on the “flexible approach” factors required by the rule. Upon the implementation of safeguards selected under such guidance, the organization will have both brought itself into compliance with the HIPAA Security Rule. While risks cannot be eliminated through such a process, if and when an incident does occur which could expose the organization to penalties it will have a sound defense.

Organizational Risk Acceptance and Security Cost Control.

While the potential consequences are perhaps less dire than criminal penalties, inappropriate delegation of risk acceptance authority may also lead to excessive spending on security safeguards and inappropriately burdensome compliance decisions. This can be demonstrated by analyzing alternative compliance decision-making approaches under one of the more problematic security standards.
The HIPAA Security Rule requires a Covered Entity to "identify[,] respond to[,] mitigate the harmful effects of [and] document security incidents and their outcomes." A "security incident" in turn is defined as an "attempted or successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations in an information system." A risk reduction perspective might well interpret these provisions to require that any and every event which meets this definition must be dealt with according to the specification. But anybody familiar with systems administration in a large enterprise knows that events which fit this definition happen constantly.

At a very basic level network connections, particularly ports accessible to the Internet, are constantly "pinged" by unknown and presumably unauthorized applications or individuals. Each such attempted connection is "attempted unauthorized access" within the regulatory definition of “security incident.” They are also almost always harmless, assuming basic security safeguards have been implemented. Nonetheless compliance with the letter of the regulation would require each one to be identified, responded to and documented.
This would seem to be a pointless exercise in security log review and documentation, except that the failure to do so could be construed as a meaningful failure if some evildoer were to succeed in gaining access through such connections – and if the regulation is interpreted to require "zero risk tolerance" it could be evidence of negligence.

Since it is also not possible to rule out the risk that someone will succeed in hacking in to your network, a zero risk tolerance approach would require the routine review of all relevant system event logs, and the documentation of all apparent attempts at unauthorized access as required by the regulation. And such documentation is presumably subject to the 6-year HIPAA document retention requirement. If the Security Rule is interpreted as requiring zero risk tolerance, however, this burdensome approach is appropriate, even though the risks presented by attempted unauthorized access would be much better addressed through good system management practices.

This would be the approach under a definition of “risk management” as equivalent only to risk reduction at the system level. But if, instead, HIPAA Security Rule compliance is a function of considered organizational risk management, it is possible to determine a level of risk which can and should be accepted – and the burdens of compliance can be appropriately balanced against their benefits.

Conclusion.

The risk acceptance decision is the key to the risk management process which is the foundation of HIPAA Security Rule compliance, and as seen above such decisions should be vested at the organizational policy level. The vesting of risk acceptance authority at a lower administrative level, expressly or by default, may well lead to dysfunctional security safeguard selections, and expose the organization to avoidable penalties.

This does not mean that the board, or CEO, COO or CFO for that matter, should micromanage HIPAA compliance or security administration. It does mean that they should fulfill their fiduciary obligations and provide guidance to those who do manage compliance and security. They should receive routine briefings on the status of security and compliance, and establish policies and procedures intended to ensure compliance. Such policies should include guidance on risk acceptance, perhaps requiring CEO or COO approval for acceptance of residual risks above certain thresholds of probability and financial exposure, and vesting risk acceptance discretion in the Chief Information Security Officer (or equivalent title) below those thresholds. Since the security program budget will also be generally determined at the organizational policy level this will also tend to prevent overspending – and where a bigger budget is necessary to reduce risks to organizationally acceptable levels, the decision will be forced upward to the level best suited to balance budgetary and security issues and needs.

Such an approach also requires organizational policy-makers to overcome any reluctance to address security issues on an informed basis, and requires security officers to overcome any tendencies they may have to build their own fiefdoms. Given the considerable and increasing importance of information security for information technology-dependent organizations, however, policy oversight is essential and the separation of security from operations is dysfunctional. HIPAA Security Rule compliance is therefore an opportunity for such organizations to “do well by doing good” – to learn to function better while ensuring they comply with the law – for those who will take it as such.

Originally published in New Perspectives in Healthcare Auditing (November 2004)

A Modest Proposal for Catalyzing Health Information Technology Adoption

2007-03-11T13:49:00.000-07:00

USING SAFE HARBORS TO REDUCE LEGAL BARRIERS TO IMPLEMENTATION OF ELECTRONIC HEALTH RECORDS AND HEALTH INFORMATION NETWORKS

This post is based on a white paper I've prepared, which proposes that state governments should take a leadership role in reducing legal barriers to electronic health record (EHR) and health information network (HIN) adoption, by implementing a regulatory “safe harbors” scheme for EHR and HIN privacy and security policies and practices. I've also developed model EHR and HIN safe harbors legislation, and would be happy to provide copies of these (and the original white paper) upon request.

Since this white paper is intended as a “straw man” to advance discussion of solutions to legal barriers – real and perceived – to EHR and HIN implementation, it does not include comprehensive legal analysis or legal citations. It does assume the reader is generally familiar with EHR and HIN issues, the privacy and security requirements of the Health Insurance Portability and Accountability Act of 1996 (HIPAA) and comparable state law principles, and to some extent with regulatory processes.

Introduction.

The lack of clear legal standards for EHR and HIN privacy and security is perhaps the fundamental legal obstacle to their widespread adoption. In their absence healthcare organizations don’t know what they have to do to avoid possible regulatory penalties and civil liabilities. Uncertainty always weighs against action, especially when the uncertainty concerns legal risks.

While some of this uncertainty could probably be resolved by minimal research and analysis, some of it is legitimate and inevitable given the current state of the law. The solution is therefore to develop legal certainty to the extent possible, at least for key privacy and security issues.

In principle this might be done by legislative mandate, but that is a blunt and inflexible instrument badly suited to emerging technology issues. Over time it might also be developed by common law, through litigation; but that would take many years at best, and the risk of litigation is itself part of the current problem.

Legal certainty is therefore more readily developed through a regulatory “safe harbors” solution. This kind of solution has been implemented for comparable problems in a number of areas, including the confusing and problematic field of healthcare financial “fraud and abuse” (the so-called “Stark” and “antikickback” laws), which provides a useful model for EHR and HIN safe harbors.

One solution to this might be federal safe harbors, but it would probably take much longer to develop and pass federal implementing legislation and develop the necessary regulations than it would to do so at the state level. Quite apart from the more complex political logistics, it seems likely it would be much more difficult to identify nationally-acceptable policies and practices given the variations among the states. A state-based strategy would instead let states whose healthcare communities felt they were ready to implement safe harbors go forward, and allow the others to follow as they were ready.

A state-based approach does raise the potential problem of non-uniformity. One state’s safe harbors may not match those of its neighbors, or its neighbors may not implement or formally recognize safe harbors at all.

While this is a legitimate concern, the fact is that there is currently no legal mechanism for development of uniformity at all. Policies and business practices tend to be developed by standards bodies and professional organizations which are not legal authorities, and are implemented ad hoc by organizations which may or may not take standards bodies’ and professional organizations’ guidance into account. The implementation of safe harbors state-by-state should therefore tend to increase rather than decrease uniformity compared to the current situation, especially if states adopting safe harbors coordinate their regulations.

By the same token compliance for organizations operating across state lines should also become simpler. Since safe harbors compliance is by definition not mandatory, interstate organizations will be able to opt-out of safe harbors which are not appropriate. Perhaps more likely, organizations operating in both states with safe harbors and those without will opt to comply and get the benefit of the safe harbors where possible. Since states which are not ready for safe harbors are also unlikely to be ready to impose legal mandates which conflict with other states’ safe harbors, interstate organizations should be better able to implement consistent policies and practices across the organization.

Uncertainties in EHR and HIN Privacy and Security Law.

There is no special legal domain for EHRs and HINs. An EHR is nothing more than a computer system used to receive, store, process and produce health information, and a HIN is any set of network technologies used to transmit it from computer system to computer system. However, the laws which apply to EHRs and HINs are the same which apply to health information in general: Principally HIPAA and a few other federal laws, plus the laws of whatever states the computer systems and the organizations which use them are located, and the individuals whose information is present in the EHR or HIN are residents.

While some requirements of these laws are fairly clear, at least with a little work, others are not. Since EHR and HIN implementation always requires changes to business practices, it is sometimes unclear how a privacy-related policy or practice should be adapted to new arrangements. Security requirements in particular are problematic, since these are almost universally risk-based and not prescriptive. In other words, they do not describe specific policies, practices or technologies which must be adopted, but require healthcare organizations to analyze security risks and make reasonable and appropriate decisions about the security safeguards they will implement.

It is therefore difficult and sometimes impossible to determine a priori whether many privacy policies and practices, and almost all security policies and practices, will be considered compliant with applicable law. This may be made somewhat clearer with a couple of examples.

On the privacy side, for example, a health care provider wishing to share health information using a HIN may be concerned whether this sharing needs to be disclosed to potentially affected patients. Under HIPAA and a number of state laws health care providers are required to give patients a notice of their privacy or information practices – that is, a general description of the ways they use or disclose patient information. However, none of these laws has any provision specifically applicable to HIN usage. The health care provider has no guidance, and must decide for itself whether HIN participation information should be included, and if so what the notice should say.

On the security side, the same provider may wonder what authentication processes it should implement for users of an EHR it is setting up. Its EHR vendor may suggest single-factor password authentication, a relatively inexpensive option. Its consultants, on the other hand, may suggest using two-factor authentication using both passwords and tokens or swipe cards, a more expensive option. While HIPAA and some state laws both indicate that some form of authentication must be implemented, they provide no guidance for choosing between single- and two-factor authentication; they simply tell the provider to do a risk analysis, and choose the “reasonable and appropriate” option.

The degree to which this kind of uncertainty is acceptable depends on the provider’s tolerance for risk. In principle, if the provider makes informed and reasonable determinations appropriate to its conditions and circumstances – if its privacy and security decision-making processes are adequate – it should not be liable if something goes wrong and health information is negatively affected. In practice, patients may be alarmed to discover that their information is being shared over a HIN and claim that the notice they received was inadequate; or in the event of an EHR security breach, may claim even two-factor authentication was inadequate.

While good decision-making practices should prevent legal liabilities in such cases, there is no assurance that they will. If there is some sort of harm to affected individuals, especially if there is a public outcry or media attention, judges, juries and even regulatory authorities may be inclined to try to find reasons to give the victims some kind of recourse. What seemed reasonable and appropriate at the time may, with the benefit of hindsight and adversarial scrutiny, come to seem unreasonable and negligent.

This kind of legal risk is a material obstacle to EHR and HIN implementation. Some organizations are comfortable with this level of legal risk, or perhaps don’t notice it. Others have a lower tolerance for legal risk, perhaps especially when it is added to the operational and financial risks of new technology implementation in the first place.

To the extent that legal uncertainties about EHR and HIN standards and practices can be reduced, then, a material barrier to their implementation will be lowered for at least some organizations. And some of these uncertainties, at least, can be dealt with by the creation of safe harbors for key policies and practices.

Using Safe Harbors to Reduce Legal Uncertainty.

Safe harbors should be carefully distinguished from legal mandates. A legal mandate is a statute or regulation (or much more rarely caselaw) which prescriptively identifies a specific legal requirement, with penalties for its violation. For example, the HIPAA privacy regulations require publication of a notice of privacy practices, and prescribe its content with some specificity. An organization which is required to publish a privacy practices notice and fails to include content prescribed by the rules is subject to regulatory penalties, and possibly exposed to claims for damages by patients claiming to have been harmed by the failure.

A safe harbor, on the other hand, does not prescribe any requirements, nor is there a penalty for noncompliance. Rather, a safe harbor describes a set of facts and the policies and practices implemented by an organization under those facts, and states an agency’s interpretation that under those facts the described policies and practices do not violate the applicable law. Organizations are not penalized for failing to implement those policies and procedures, but those which choose to do so are assured they will not be penalized. Organizations which choose not to do so have no such assurance, but are not necessarily in violation of applicable law and therefore not necessarily subject to penalties.

A safe harbor therefore reduces legal risk, as opposed to a legal mandate which actually creates it. A safe harbor scheme would therefore reduce legal risks in EHR and HIN implementation, and so reduce this barrier to implementation, as opposed to legal mandates which would only raise it higher.
A safe harbor scheme can also accommodate the problematic issue of different and changing technologies and circumstances better than a legal mandate scheme. This problem is the legitimate reason why the HIPAA security regulations are risk-based rather prescriptive: It takes much longer to change statutes than it does regulations, and longer to update regulations than to update regulatory guidance. Any specific prescriptive requirements would be at risk of becoming obsolete, and perhaps counter-productive, more quickly than they could be revised.

For this reason HIPAA itself – the legislation rather than the regulations usually identified with it – deliberately established a regulatory structure which authorized and directed agency issuance of appropriate regulations, to accommodate changing and variable needs and circumstances. The HIPAA enforcement regulations in turn establish a dispute resolution structure which includes publication of interpretive decisions to help guide healthcare organizations – though it appears it will be some time before a significant number of cases reaches that level.

This structure is not unique to HIPAA, and in fact is relatively well-developed in the healthcare “fraud and abuse” area. This is a field in which legislation established draconian penalties for violations of broad, confusing and counterintuitive laws. Given the breadth and difficulty of interpretation of these laws, a risk-averse interpretation would tend to rule out many legitimate and even beneficial business arrangements and transactions. In other words, the fraud and abuse laws created legal uncertainties which may be a material barrier to valuable activity.

In order to overcome this barrier, the U.S. Department of Health and Human Services publishes safe harbor regulations interpreting the fraud and abuse laws as applied to specific sets of facts. Less formal guidance documents, as well as opinions on specific factual situations presented in letters requesting guidance, provide additional assurances which help reduce the risks to healthcare organizations seeking to develop business arrangements and transactions which they otherwise might avoid altogether – even when they might provide material benefits to patient care and administration.

A comparable regulatory scheme for health information privacy and security in EHR and HIN environments could issue comparably useful safe harbor regulations and interpretation. For example, in the case of patient notice of HIN participation, an agency could issue regulations (or guidance) describing the form and content of one or more provisions which would provide adequate notice. In the case of EHR authentication, an agency could issue regulations specifying factors which would be considered reasonable and appropriate and therefore in compliance with the law. In neither case would healthcare organizations be required to use the specific provision or authentication factors, but those which chose to do so would be assured their implementation was consistent with the agency’s authoritative interpretation of the law.

Developing Content for EHR and HIN Safe Harbors.

An EHR and HIN safe harbors scheme would be adaptable to – and should in fact be based upon – prevailing industry standards and best practices, and would also be transparent and open to the public. Legislation might require implementation of formally-developed industry standards, as HIPAA does for transactions, but that is probably more appropriate for prescriptive legal mandates rather than safe harbors. A better strategy would be to develop proposed safe harbors based on research into healthcare standards and practices, to be finalized after a public comment period open (as is generally required for regulations) to any interested party.

A public safe harbors development process would present a much greater opportunity for public understanding of and input into EHR and HIN policies and practices than current practice. Currently, EHR and HIN policies and practice are developed ad hoc, to some extent in a few standards groups but principally in negotiations among healthcare organizations and vendors. Not only is this activity mostly unknown to the public, for the most part there is not even an opportunity for public understanding and input.

Ad hoc development also leads to avoidable divergence in EHR and HIN policies and practices among organizations. This in itself is a barrier to widespread implementation, since organizations using different policies and practices often find it difficult or even impossible to share networks and information, or find it difficult to adapt to each other when they try. Publicly-developed safe harbors would present common policies and practices all participants could use, again lowering a barrier to implementation.

As noted above, and reflected in HIPAA, there is a valid point that technologies, economic conditions and operating environments are diverse and changeable, often rapidly. However, this point argues for careful execution of a safe harbors strategy, rather than its avoidance. Safe harbors should be carefully chosen and defined to apply to and solve common problems, at a sufficiently general level that they should not need frequent revision. This is also an argument for the inclusion of additional regulatory guidance opportunities, through reports, publications and perhaps opinion letters, so that new developments and distinctive circumstances can be addressed.

In practical terms, this process might work for the privacy notices and authentication examples discussed above as follows. Given appropriate enabling legislation, the agency authorized to develop EHR and HIN safe harbors would identify a set of key issues for which uncertainty about legal privacy or security standards appeared to be discouraging EHR or HIN implementation. These issues might very well include privacy notice content and authentication. Initial proposals for their resolution would then be solicited from appropriate stakeholders and interest groups, as well as the public.

Based on this initial feedback, the agency would develop proposed regulations and publish them for comment. The proposed regulations would be sufficiently detailed to permit meaningful comments; for example, the proposed privacy notice regulation might provide one or more provisions which could be adopted, while the proposed authentication regulation might specify that use of two-factor authentication would be considered compliant. Following comments on the proposed regulations, the agency would develop and publish final regulations.
Organizations could choose to implement the policies and practices described in the regulations, and have the agency’s assurance they were in compliance; organizations which chose not to do so, would not be penalized per se. For example, an organization could still conclude, based on its HIPAA risk analysis, that two-factor authentication was not a reasonable and appropriate safeguard in its environment. This decision might be open to question in the event of a regulatory investigation or litigation, especially arising from an incident raising the question of the adequacy of authentication, but the mere fact of noncompliance with the safe harbor would not be grounds for a penalty.

Implementation of the Safe Harbor Scheme.

An EHR and HIN safe harbors regulatory scheme would be no silver bullet. Given the complexities of federal and state jurisdiction no agency would be able to cover all the issues. And while ideally, perhaps, EHR and HIN safe harbor regulations should be a federal function, creating significant new federal agency authority can take a long time. Further, achieving a national consensus on appropriate safe harbors is likely to be much harder than achieving it within a state or region. Federal safe harbors are not likely to be available for some time at best.
State-by-state safe harbors, on the other hand, raise the questions of HIPAA applicability and the potential for excessive and unnecessary cross-state variation. While the former question needs more analysis, HIPAA does provide that state laws which are more protective of information control where both HIPAA and state laws apply.

State-based regulations which establish safe harbors more protective than HIPAA should therefore provide assurances of compliance with both state and federal law. Where HIPAA does not provide a clear standard, while state agencies may have limited authority to interpret HIPAA, the fact that a state agency has determined that a given policy or practice provides reasonable and appropriate safeguards, following a public comment process, should be very persuasive for HIPAA purposes.

Safe harbors could therefore be implemented using model legislation for state adoption. In order to maximize uniformity, the states implementing such a scheme could establish a coordinating group to keep their safe harbors (and perhaps other health information laws) consistent.

This would not be a complete solution, of course, unless all the states and territories adopted the same scheme and safe harbors, and that is not likely any time soon. Even with a coordinated state-by-state scheme, interstate organizations operating in both states with safe harbors and those without (or those with materially different safe harbors) would face the question whether they could adopt uniform policies and practices across the organization, and comply with both states’ laws.

Upon analysis, this problem becomes something of a red herring. Interstate organizations already face the problem of actually or potentially conflicting state requirements, with much less guidance and uniformity than would be possible under a state-by-state safe harbors scheme. Such a scheme would therefore be a clear improvement over the current situation.

The uniformity problem would only arise in the first place for interstate organizations operating in both safe harbor and non-safe harbor states if there was a conflict between the safe harbor of the one state and some legal requirement of the other. One reason such conflicts seem unlikely to arise is that a safe harbors scheme is probably more likely to be adopted by states whose legislators and regulators feel competent in addressing health information technology issues. If legislators and regulators in non-safe harbor states do not feel sufficiently competent in this area to adopt a safe harbors scheme, it seems unlikely they would feel competent enough to implement legal mandates in this area in sufficient depth to create a conflict with other states’ safe harbors.

Should this problem arise anyway the nature of safe harbors compliance would allow interstate organizations to resolve it, by adopting policies and practices compliant with the mandate; there would be no penalty for failing to comply with the safe harbor. The same principle would allow resolution of a conflict between different safe harbors provided by different states, should that arise, since an interstate organization could choose between available safe harbors without penalty.

A coordinated state-by-state safe harbors approach would therefore allow the incremental development of national uniformity. States which were ready to address EHR and HIN issues could adopt safe harbors reflecting well-accepted, reasonable and appropriate policies and practices; other states could follow their lead when they were ready and if they found such safe harbors acceptable. Healthcare organizations would have an incentive to adopt safe harbor policies and practices to gain some currently available legal certainty, but could move to them as and when it worked for them without penalty.

Conclusion.

As a general rule there are good reasons for governments to tread carefully on technology-related issues, especially in emerging fields like EHR and HIN implementation. However, we seem to have reached a point at which legal uncertainty is itself a barrier to potentially beneficial progress, and governments – as the principal source of the laws – may be especially well-suited for resolving this kind of uncertainty. A carefully managed safe harbors strategy would allow for the reduction of legal uncertainty without imposing prescriptive requirements which would be hard to change if and when they became obsolete. While it would probably be most valuable in the long run for this to be a federal function, in the short run the states could assume a leading role, and reduce legal barriers to EHR and HIN implementation by reducing its attendant legal uncertainty.

The Role of Legal Counsel in Information Security Risk Assessment and Strategic Information Security Decisions

2007-02-13T19:41:00.000-08:00

Legal counsel can and should play an important role in information security legal compliance and risk management. While the implementation of many security safeguards requires substantial technical knowledge, the development and selection of specific security policies, procedures and technical requirements for purposes of legal compliance and risk management requires the integration of such technical knowledge with legal interpretation and strategic risk management insight.

Specification of Legal Security Issues.
Legal requirements for security compliance, whether under HIPAA, Gramm-Leach-Bliley, emerging common law or almost any other law, are organizational obligations, not technical specifications. (The California Database Protection Act and comparable laws, which create incentives for encryption of personal information stored in databases, may be an exception. Even in this case, however, the law does not specify the type or strength of the encryption, or make encryption mandatory.) Any given organization may be subject to one or more set of legal security requirements, depending on the kind of activities it engages in and the jurisdictions where it does business.

> Legal Task: Identification of security laws applicable to organization, based on jurisdictions and activities.

As a rule, security legislation and regulations do not have any “safe harbors,” so there is no security control or set of security safeguards whose adoption can be guaranteed to make an organization compliant. Rather, these laws require organizations to assess and manage information security risks, to a degree usually framed as “reasonable and appropriate,” or as applicable to “reasonably foreseeable risks.” Unfortunately, “risk” is a multi-dimensional concept, a factor which always should be but too often is not taken into account in security risk assessment and management.
The usual formulation of information security objectives, which are the objectives against which security risks are determined, is the “CIA triad,” for “confidentiality, integrity and availability” – that is, the extent to which a given asset is protected against unauthorized viewing, use or alteration. In some settings, such as financial system assessment, the additional objective of “accountability,” meaning the ability to strongly identify participants in transactions, may also be a key objective.
These security objectives are frequently in conflict; for example, any process which protects confidentiality by making asset access more difficult will tend to decrease availability to the same degree. When security risk objectives conflict their resolution is a matter for organizational policy.

> Legal Task: Ensure security objectives of organization are consistent with legal obligations of the organization.

Information Security Risk Assessment.
The foundational process for information security is risk assessment. In this process an appropriate professional or team of professionals undertakes a structured review of the security controls and safeguards used in connection with an organization’s processes, physical facilities and technical systems used to receive, store, process and transmit legally-protected data.
The results of a risk assessment may be used (1) to identify gaps or weaknesses which might put the protected data at risk, supporting the recommendation or development of appropriate new or supplemental safeguards and controls to fill the gaps or mitigate the weaknesses; or (2) to confirm an organization’s compliance with security standards. The former type of assessment is frequently called a security “gap analysis,” while the latter is sometimes, but not always, referred to as a security “audit.”
From a lawyer’s point of view both types of assessment are factual investigations, and assessment reports are (or should be) findings of fact. It should be noted, however, that assessments sometimes purport to go beyond findings of fact, to conclusions of law; e.g., that a given organization is or is not “HIPAA compliant.” This is understandable when the objective of the assessment is to determine compliance, but the actual determination whether an organization is in compliance with the law is something only a lawyer is trained and authorized to do. Quite apart from issues of the unauthorized practice of law, the organization might well get an incorrect answer about its compliance status.

> Legal Task: Help develop risk assessment scope of work to ensure focus on appropriate objectives and fact-finding limitations.

A compliance assessment therefore should either be a joint lawyer/security professional project or a two-stage project in which the legal implications of the security professional findings are determined by a lawyer. On the fact-finding level there are a number of possible risk assessment methodologies available, none of which are required as a matter of law for private or state governmental organizations.
Federal agencies are supposed to use the risk assessment methodologies published by the National Institute of Standards and Technology (“NIST”), which has been influential in federal security regulation development and therefore should be taken into account in assessing compliance with federal regulations. A very few industries have developed or are developing their own appropriate methodologies, especially the banking and energy sectors, and the major consulting firms tend to have proprietary methodologies.
Generally, any information security risk assessment will start with an identification of (1) security “assets,” (2) “threats” to those assets, and (3) operational and system “vulnerabilities” to identified threats. While precise definitions vary, generally these terms refer to the following:
• An “asset” may be information as well as operational resources such as software applications, bandwidth and memory, and networked devices and equipment, which the organization is legally obliged to protect, is materially necessary to operations, or is of value to the organization.
• “Threats” are the various agencies which may harm or interfere with assets, including human threats such as hackers and malicious insiders; environmental threats such as facility fires, power outages and burst water pipes; natural threats such as floods, earthquakes, and the like; and technical threats such as computer viruses, worms and spyware (arguably a subset of human threats, since they are of human origin).
• “Vulnerabilities” are those operational and system characteristics which make it possible for specified threats to harm or interfere with specified assets. Some vulnerabilities may be obvious and easily resolved, as with implementation of a firewall to prevent unauthorized external access to a network. Others may be the result of normal or even generally beneficial features of a process or system element, as where remote database access to support telecommuting creates unavoidable (though to some extent reducible) risks that an unauthorized individual will “spoof” an authorized user’s identity to gain network access.
Once assets, threats and vulnerabilities have been identified, the next step in risk assessment is “impact” and “control” analysis, to make a “risk determination.” Risk is typically considered a function of the probability that a given threat will cause harm to a given asset, given the existing vulnerabilities. The finding at this stage is sometimes called the “inherent risk.”
Risk assessment can be a difficult, burdensome and uncertain process. In large or complex organizations and/or systems it may only be practical to assess a sample of the processes, facilities and/or systems, though choosing reasonably representative samples may be problematic.
Assets are usually readily identifiable, but doing so requires defining the perimeters of the processes and systems under assessment, and inventorying the information, devices, and equipment which constitute its assets. It is also important to try to assign values to assets, and in this connection it should be noted that the term “asset” has something of a specialized meaning in the risk assessment context.
Ordinarily, assets only have a positive value, such as the market price at which they can be sold, or their value to the organization in operational support, which might be measured by the cost of replacement. For risk assessment purposes, however, the liability or penalty “value,” meaning the exposure of the organization to liabilities and/or penalties due to loss, disclosure or misuse of the asset should also be estimated.

> Legal Task: Help identify assets organization is legally obliged to protect, e.g. legally-protected information, licensed software and trade secrets, etc.

> Legal Task: Estimation of liabilities and/or penalties associated with loss, disclosure or misuse of assets identified for risk assessment purposes.
Like assets, most types of threats are usually identifiable at a categorical level though some, especially threats caused by malicious software, are constantly evolving. However, the identification of the specific threats applicable to a given asset requires a detailed review of the operational environment in which the asset is kept, used and/or transferred.
Threats can generally be categorized as follows:
• Human threats, from insiders or outsiders (e.g. hackers), who may unintentionally or deliberately access, use, modify, transfer or harm assets.
• Physical facility threats such as power failures, fires, burst water pipes and other event harming the facilities or equipment used in connection with the assets.
• Environmental threats, such as floods, earthquakes and tornados, which may also cause harm to facilities or equipment.
• Technical threats such as computer worms, viruses and spyware (which might be considered a subcategory of human threats since humans create them), as well as system-related issues such as application instability, etc.
Vulnerabilities are also functions of the operational environment, and are identified by the known characteristics of the operating environment, including those of the specific technical systems, buildings and equipment, as well as those of human beings in general. Whether or not a given characteristic is a vulnerability depends entirely upon the assets and threats presented in the given environment.
An assessment also inventories existing security safeguards and controls (two overlapping terms, in this context sharing the meaning of protections against potentially harmful events). These are frequently categorized as administrative, physical and technical, though there is an emerging recognition of governance controls as an important category as well. These categories break out as follows:
• Administrative safeguards are the policies and procedures used to manage operational processes and human activities involving or pertaining to assets and vulnerabilities. These would include policies and procedures pertaining to hiring and employment, authorization for and management of asset access and use, etc.
• Physical safeguards are the policies, procedures and physical requirements applicable to the buildings and equipment relevant to asset management, such as locked-door requirements, key issuance, fire suppression, disaster recovery plans, portable device (e.g. laptop) protection policies, etc.
• Technical safeguards are the policies, procedures and system requirements controlling access to and use of software and information in devices and/or on the network. Technical safeguards include system configuration requirements, user identification and authentication procedures and processes (e.g. password issuance and management), malicious software screening and disposition, encryption of data, etc.
• Governance controls constitute the policies and procedures used to provide security oversight. While it has long been recognized that factors such as demonstrated executive commitment and reporting, accountable security officers and appropriate security training are essential for effective security, governance controls have not tended to be a separate subject of security assessment (though some aspects, such as training, are sometimes assessed as part of administrative safeguards). With the emergence of security as a regulatory compliance issues, governance control assessment is at least prudent if not necessary to avoid penalties and liabilities, including penalties or liabilities applicable to individual officers or directors responsible by law for organizational governance.
The effectiveness of policies and procedures is in many cases at least partially a legal question, as where employees are supposed to be subject to discipline for policy violations, or oversight policies are implemented to avoid or minimize liability and penalty exposures.

> Legal Task: Review legal effectiveness of policy and contractual documents used as security safeguards and controls.

The most difficult step in risk assessment may be risk determination, since this depends upon probability information which may not be available, or if available may not be reliable. There is currently no central repository of threat or security incident information, and no mandatory reporting, so to date there is no robust information on the incidence of most threats.
Some security professionals argue that certain vulnerabilities are so well known and so easily corrected (such as the use of weak passwords) that “due care” requires their correction. This suggests that some specific safeguards may be required, in at least some specific settings, as a matter of law. There is little or no specific law on this point, so the identification of such safeguards would seem to be a matter for determination by properly qualified security experts.

> Legal Task: Work with security professionals to identify safeguards which may be required to meet the applicable standard of care, and basis for such identification.

Impact information may be more available but more problematic, since assessment according to different security objectives (as discussed below) may lead to different impact outcomes. For example, electronic health records (“EHR”) systems are used to store and process personal health information, which is required to be protected under HIPAA and is accorded highly confidential status under not only HIPAA but a variety of other laws. At the same time, an EHR may be used to support critical clinical care, so that a failure of availability might cause erroneous treatment decisions leading to a patient’s serious harm or even death.
Note that in both cases the impact determination is based on a projection of legal exposure. In this case, the differential impacts are that a failure to provide confidentiality protections judged adequate in a HIPAA administrative enforcement proceeding might lead to a few thousand dollars in civil penalties, while a treatment error causing a patient’s death could lead to a multimillion dollar negligence judgment.
This risk assessment step therefore requires legal insight and analysis. And this scenario also demonstrates the reason why a security risk assessment should only be undertaken with a clear understanding of the organization’s risk management strategies and tolerance, and the security objectives of processes and systems under assessment.

> Legal Task: Review and analyze legal implications of risk assessment findings, including alternative liability and penalty exposures under different scenarios.

Strategic Information Security Decision-Making.

Security risk management and compliance decisions will always be subject to second-guessing in hindsight, by regulators or counsel for parties alleging harm caused by a security breach. The only effective response to this is to implement appropriate security risk assessment and management diligently and in good faith.
The information security legal compliance process therefore resembles the processes used by organizational fiduciary officers in compliance with the corporate “business judgment rule,” and to minimize organizational and officer exposures to criminal penalties under the Federal Sentencing Guidelines. Such processes require informed executive oversight and careful documentation. Advice from qualified experts and legal counsel can help demonstrate due diligence, and legal counsel can be helpful in developing the strategy for properly documenting the process for use as defensive evidence, if needed.

> Legal Task: Assist in development of organizational oversight policies and procedures for security compliance oversight and risk management.

> Legal Task: Ensure adequacy of security compliance documentation for evidentiary purposes.

Legal counsel may also be helpful in making hard choices, as where a technical solution is available but expensive and a policy control is under consideration as an alternative. A good security consultant can make appropriate findings identifying security vulnerabilities, and can recommend alternative solutions, but the organization’s accountable executives must make the decision whether or not the risks associated with the policy control alternative are acceptable.
This is fundamentally a governance-level decision, which should be made in accordance with the organization’s strategies for managing its full portfolio of risks – financial, operational, legal, and so on – which includes but is not limited to information security risks. At the organizational level there are four basic risk management strategies, any or all of which may have implications for security management:
• Risk avoidance, a strategy under which an organization determines that its exposure is simply too great in performing some specified activity, and avoids engaging in that activity. For example, a bank might find the lower costs of offshore processing of customer information attractive, but conclude that the lack of adequate oversight of and legal recourse against offshore processors for failing to protect the information makes this option unacceptable.
• Risk assumption is a strategy under which risks are understood and deliberately accepted, as an informed policy decision. Since risks can never be reduced to zero as a practical matter, risk assumption is an inevitable element of risk management. If risks to be assumed can be accurately projected, it may be possible to reserve against them. Any organization which fails to assess its risks is essentially adopting a strategy of assuming all risks by default.
• An uncommon strategy which may be becoming more available is risk transfer, under which the exposed party obtains some coverage for its own risk exposure by having a second party assume some or perhaps all of the risk. Insurance, where available, is one example of security risk transfer; so is an indemnification clause in a contract with a party hosting or otherwise performing services affecting assets.
• The most common strategy, and sometimes the only one recognized as a security strategy by the less sophisticated, is risk reduction. Risk reduction includes the implementation of whatever policies, procedures and technical solutions may be necessary or desirable to reduce identified risks to a level at which they can be assumed.
The precise mix of strategies an organization uses depends in part on what is available, both practically and as a matter of law. Some risks are inherent in an organization’s mission and cannot be avoided; for example, fraud is an inherent risk for financial services, and medical error is an inherent risk for health care providers. And risk transfer, in particular, may or may not be option, depending on the availability of insurance or the ability to transfer risk to other parties by indemnification.

> Legal Task: Assist in negotiation of insurance coverage and/or contracts transferring risk, where available.

The bottom line on an organization’s security strategies depends upon its security risk tolerance. While there have been arguments that there is or can be a “return on investment” from security activities, security is usually perceived as a zero-sum game: Any resources invested in security are taken away from other possible uses. The organization, therefore, must make a policy decision about how much it is willing to allocate to security, based on the availability of resources and the security-related risks it is willing to assume.
This kind of decision must be informed, but cannot be determined by security risk assessment findings. Information security legal compliance and risk management is just one of the portfolio of risks any organization must manage. An over-allocation of resources to security which harmed the organization’s ability to fulfill its mission, for example, could be more detrimental than many security events.
Deciding whether or not a given level of security risk is tolerable therefore depends less on an understanding of specific security threats and vulnerabilities, than on an understanding of their implications for the organizational mission. Potential financial, operational and reputational harms and legal penalties associated with security risks must be balanced against potential harms associated with their prevention, and there is no a priori formula for striking such a balance. Decisions like this are in the final analysis the fiduciary responsibility of the officers and board of the organization, and the role of both lawyers and security professionals at this level is to provide these officers and directors with the information and professional advice they need to make them.

> Legal Task: Provide legal information and counsel to executive officers and board in the strategic management of the organization.

Conclusion.

Lawyers should play an active role at all levels of the information security risk assessment process, from defining the scope of the assessment and determining the legal effects of policies and procedures under assessment, through interpretation of the legal implications of an assessment to advise the officers who must decide what it means to the organization. Technology-dependent organizations should therefore identify (or develop) and make use of attorneys who understand how to work with information security concepts, documentation and professionals, to help them appropriately manage their information security compliance obligations, and manage their security-related risks. Conversely, lawyers serving such organizations should develop appropriate expertise, or identify and make use of outside counsel when dealing with potentially important security issues. Either way, this means involving legal counsel in information security risk assessment and management processes and procedures.

InfoSec Risk-Shifting and Consumers

2007-02-06T10:52:00.000-08:00

One of my pet peeves (I have quite a few) is the way that we tend to use the term "risk management" as if it had a generally accepted meaning everybody understands. For infosec and most other IT professional purposes risk generally means a "hazard" associated with IT usage, in more formal terms described as a function of the probability of an event with negative consequences occurring and the potential severity of such harm.

From an IT and infosec professional's POV, "risk management" is what you do to reduce the likelihood of an identified, potential negative event or class of events, its harmful consequences, or both. Safeguards and controls are selected depending on whether their associated cost is reasonably proportionate to the expected benefits in reducing risks.

This concept set is a little fuzzy around the edges, but is generally accepted as a viable algorithm for IT management and infosec. (I actually think don't actually think this algorithm works all that well in these areas either, and I think I've got a solution for that, but that's a topic for a future post.) However, I don't think this particular algorithm is recognized and accepted by one very important IT stakeholder group: Consumers.

Consumer advocates will not find the infosec/IT professional cost-benefit model very attractive for a simple reason: It generally shifts residual risks to them. Any cost-benefit-based risk management strategy will inevitably wind up determining that some risks are not worth the cost of elimination. If this model is the legal standard of care - which it in fact is under HIPAA and GLBA, and other laws and standards - that means that an organization which has decided not to protect against such risks is not liable if a negative event in that risk range occurs. If the individual(s) affected by a negative event have no recourse, they have assumed the risk; in other words, the residual risks have been shifted to the consumer.

For an example, consider a mythical ecommerce company which gathers customer data as part of financial services it provides. The company is subject to the Gramm-Leach-Bliley Act, and so must provide security safeguards for this data. It selects these safeguards based on the standard cost-benefit model, and decides it would not be cost-effective to implement, say, two-factor authentication for access to customer transactions data. It then experiences a security incident involving theft and fraudulent misuse of customer data, through an exploit which could have been prevented by two-factor authentication.

Is the company liable to the customers who have been harmed? I would say probably not, if the standard of care is set by Gramm-Leach-Bliley and the company performed a reasonably competent risk analysis whose data supported going with single- rather than two-factor authentication. (Yes, I know Gramm-Leach-Bliley doesn't provide for a cause of action, but trust me I could write up a complaint using the regulatory standard to set the negligence standard of care.) I'd also say it probably isn't exposed to regulatory penalties from the FTC, for the same reason.

If you're one of the consumers harmed by this incident the fact that the company's cost-benefit analysis justified the decision to leave you exposed and then take all the harm yourself is probably not just cold-hearted, it's probably insulting. And if you were one of the consumers, you'd probably feel that way too.

The problem is that when we look at the world as individuals (not just consumers!) we don't do it through cost-benefit lenses, and (notwithstanding Milton Friedman, may he rest in peace) that's probably a good thing. We consider that we have our own rights and interests, and don't want to be harmed (materially) just to save someone else some money. And that's what being on the receiving end of standard model risk management looks and feels like, if you're the victim of residual risk-shifting.

I don't know quite what the solution is for this dichotomy of perspectives; I think it is quite common in many areas - I rather suspect it is the rule rather than the exception. I do know that it makes infosec public policy and legal standards inherently unstable, because use of the standard cost-benefit model means that there will unavoidably be consumers aggrieved at being (or at least feeling) victimized, and so there will be public policy pressure by privacy and victims' advocates to shift the risks back to the companies.

At the public policy level, I think this means we need to have robust discussions about what, exactly, we mean by "risk," and what the trade-offs might be. At the company level, I think we need to be very careful to think through how residual risks might be shifted by the risk management strategies we adopt, and whether that in itself is acceptable.

After all, the more infosec residual risk you shift to consumers, the greater the risk you will create aggrieved plaintiffs and/or advocacy and pressure groups. In the final analysis, a low-cost infosec strategy just might wind up turning the residual risks you tried to shift into negative publicity, lawsuits and regulatory action . . .

Vista: Secure enough for hospital life support?

2007-02-01T14:38:00.000-08:00

I've been wondering for some time about standards for the stability and security of applications and operating systems supporting critical systems, like electronic medical records, and especially those applications providing decision support (e.g. computerized patient order entry). I've tended to punt via disclaimers about not using them for critical systems, which users ignore at their peril (and ignore them they do).

Maybe Vista will set a new standard? Billg seems to thinks so, with a number of (very valid) qualifiers. And we'll have to see what the EULA says . . .

Excerpt from an interview with Bill Gates, from Digg: http://www.our-picks.com/archives/2007/02/01/bill-gates-vista-is-so-secure-it-could-run-life-support-systems/(

Journalist: Let’s imagine a hospital where life support systems are running Vista. Would you trust it with your life?

Bill Gates: . . . The answer to your question is that, absolutely, Vista is the most secure operating system we’ve ever done, and if it’s administred properly, absolutely, it can be used to run a hospital or any kind of mission crytical thing. But it’s not as simple as saying “If you use Vista, that happens automatically”. The issues about patient records and who should be able to see them, the issue about setting up a network, so that authorized people can connect up to that hospital network, the issue about having backup power, so that the computer systems can run even if the generators go down. There are a lot of issues to properly set up that system, so that you have the redundancy and the security walls to make sure it fullfils that very crytical function. So we are working with partners to raise their skills to make sure that when get involved in an installation like that they can make it secure. So I feel better about Vista than any other operating system, but there’s a lot of things that need to be done well, and we’re certaintly committed to step up and make sure these security issues are ieasier and better understood.

Security Incident Response Policy

2007-01-29T08:53:00.000-08:00

The following policy is intended to set up a structure for security incident response for healthcare organizations. It takes into account HIPAA as well as state security incident response laws, as well as other federal requirements and the other information security laws of most US states. (It might well be consistent with all of them but I've only had reason to check it against maybe 3 dozen states.)

Obviously it is designed for a larger organization, but should be readily adapted to smaller - the real point is to be sure to identify the tasks which have to be accomplished and designate accountable individuals to handle them. It also takes its place in a broader legal architecture (policy and procedural structure) which includes some defined terms and acronyms whose definitions I haven't bothered to include here - sorry! - but I think they should be easy to figure out by context.____________________________________________________________________
© 2005 John R. Christiansen
Subject to Creative Commons License
Attribution Share-Alike 2.5 License

ORGANIZATION NAME Security Incident Response Policy

Information Security Policy No. __

1. Objectives of this Policy

The objectives of this Policy are to help assure:

The confidentiality, integrity and availability of Protected Information held by ORGANIZATION, including but not limited to protected health information as defined by Health Insurance Portability and Accountability Act of 1996 and its implementing regulations ("HIPAA"); and

The operational integrity of ORGANIZATION's Information Systems.

2. Scope of Policy.

This Policy is intended to help accomplish its objectives by providing guidance to ORGANIZATION Workforce and Contractors, so that they will be able to:

Recognize events or circumstances which may indicate that a Security Incident is occurring or has occurred;

Know who is responsible for and authorized to respond to possible Security Incidents; and

Know the procedures which should be followed in responding to possible Security Incidents.

3. Recognizing Security Incidents

3.1 A Security Incident is any action or event which:

Provides an unauthorized person with access to and/or the ability to use, disclose, modify or destroy Protected Information; or

Permits an unauthorized person to modify the functioning of ORGANIZATION's Information Systems, including any equipment or device and any software application or operating system which is a component of an Information System; or

Permits a software application which is not authorized under the Acceptable Use policy to access or perform actions affecting Protected Information or the functioning of any Information System or component of an Information System.

3.2 ORGANIZATION Workforce and Contractors are only authorized to access, use, disclose, modify or destroy Protected Information, and to access, use and perform activities on ORGANIZATION information systems, in compliance with ORGANIZATION policies. Any action by a member of the Workforce or a Contractor which may provide access to or affect Protected Information and/or an Information System which is not in compliance with ORGANIZATION policy may therefore be considered a Security Incident.

3.3 Individuals and entities which are not members of the Workforce or Contractors are not authorized to have access to Protected Information or Information Systems without specific authorization by the CISO or other Authorized Security Officer. Any action which may provide access to or affect Protected Information and/or an Information System by an individual or entity who is not part of the Workforce or a Contractor and is not specifically otherwise authorized by an Authorized Security Officer, may therefore be considered a Security Incident.

3.4 Both direct and indirect actions which result in access to or affect Protected Information and/or Information Systems may be considered security incidents. Some possible types of Security Incident therefore include:

An employee or Contractor viewing Protected Information in a database the individual is not authorized to access under ORGANIZATION policy.

An employee or Contractor downloading software which is not permitted under the Acceptable Use Policy.

An unauthorized third party ("hacker") using a falsified user name and password to gain access to Information Systems.

An unauthorized third party seeking Information System access control or other information by pretending to be an individual authorized to obtain such information ("social engineering").

An email or other communication purporting to be from an authorized party seeking Protected Information or information potentially useful in obtaining Information System access ("phishing").

A software virus or worm ("malware") interfering with the functioning of personal computers which are part of an Information System.

This is not intended to be a comprehensive list of possible types of Security Incident.

4. Security Incident Priorities

Security Incidents shall be ranked as follows:

4.1 Categories

Critical:

Risks: Exposure to criminal penalties; exposure to major financial losses; potential threat to life, health or public safety; major damage to reputation or operations

Examples: Employee theft of Protected Information; disruption of or denial of service by Critical Systems, including clinical decision-support applications, financial reporting systems, and electronic medical records information; unauthorized access to security administrator applications or information

Moderate:

Risks: Exposure to minor financial losses; minor damage to reputation or operations

Examples: Employee views medical record of fellow employee without authorization; worm causes fraudulent mass emailing from infected systems; website is defaced

Minor:

Risks: Exposure to minimal financial losses; minimal or no damage to reputation or operations

Examples:"Phishing" email is received; employee accesses prohibited websites

Suspicious Activities:

Observations indicate possibility of past, current or threatened security incident, but may be consistent with authorized or non-harmful activities.

Examples: Access logs show limited number of unsuccessful attempts by authorized user; employee loiters near restricted work area beyone his authorization; user returns to workstation to find new application started without her authorization

5. Information Security Incident Response Team

The Information Security Incident Response Team ("ISIRT") will be responsible for response to all Critical and Material Security Incidents, and shall develop procedures and delegate responsibilities for response to Moderate and Minor Security Incidents to the Security Team. ISIRT membership shall include Security Team staff, representatives of the principal departments of ORGANIZATION, and representatives of the CIO, the Law Department, Public Affairs and Human Resources. The ISIRT will be chaired by the CISO.

The ISIRT will be responsible for developing and maintaining incident response procedures, and will lead and coordinate responses to Incidents. The ISIRT shall establish contact procedures and responsibilities to ensure that appropriate individuals are contacted for response as needed. Members of the ISIRT shall be responsible for advising and assisting the Incident Leader in response to Critical and Material Security Incidents. At all times, the ISIRT shall have appropriate members on-call to respond to incidents.

The ISIRT shall maintain relationships with and contact information for local, state, and/or federal law enforcement agencies, Internet Service Providers (ISPs), third party contractors, outside legal counsel, managed security providers and technology experts as the ISIRT deems appropriate or helpful.

6. Security Incident Reporting

All members of the Workforce and Contractors are required to report possible or suspected Security Incidents when they observe activities or records which reasonably seem to indicate their occurrence.

6.1 Observed Policy Violations.

Potential or suspected Security Incidents in which Workforce members and/or Contractors are observed acting contrary to policy shall be promptly reported to the Information Asset Supervisor responsible for oversight of the Protected Information and/or Information System element which is implicated, unless the Information Asset Supervisor, an Authorized Security Officer or a member of the Security Team is the individual suspected of acting contrary to policy.

6.2 Records of Incidents.

The Security Team shall be responsible for the review of audit trails, log files and other records of activity involving Protected Information and Information System usage.

6.3 Malicious Software.

All members of the Workforce and Contractors are required to immediately report to the Security Team the possible presence of software viruses and worms, and any spyware which appears present or to be affecting the performance of any personal computer or other device or application they are using.

6.4 Social Engineering.

All members of the Workforce and Contractors are required to immediately report to the Security Team if they receive any communication from an individual requesting Protected Information and/or information potentially useful in obtaining Information System access or use, from any individual whose authority to obtain such information is not known and cannot be confirmed with the applicable Information Asset Supervisor. This requirement applies to all communications, whether face-to-face, by telephone or email, or otherwise.

6.5 Violations by Accountable Security Personnel.

Potential or suspected Security Incidents involving an Information Asset Supervisor, Authorized Security Officer or member of the Security Team shall be promptly reported to the [COMPLIANCE OFFICER/LEGAL OFFICER/COO/OTHER].

7. Responding to Security Incidents

All reports of potential or suspected Security Incidents shall be documented upon receipt. Any actions taken in response to a potential or suspected Security Incident shall be documented in the form provided by the ISIRT. The originals of all Security Incident documentation shall be kept by the ISIRT according to the Policies and Procedures Documentation Policy.

7.1 Malicious Software Incidents.

The Security Team shall respond to all Security Incidents involving malicious software according to the Malicious Software Policy, Policy No. __.

7.2 Information Asset Supervisors.

Upon observing or receiving a report of a potential or suspected Security Incident the Information Asset Supervisor shall:

Notify the ISIRT and cooperate with all ISIRT response requests.

Document the observation or report.

If the observation or report indicates the involvement of a Workforce member or Contractor, suspend the access of the individual(s) involved to the Information System pending investigation.

7.3 Critical Security Incidents.

An Incident Leader will be designated for each Critical Security Incident. The Incident Leader will be responsible for identifying and coordinating responsive actions; identifying and convening the members of the ISIRT necessary or appropriate for response to the incident; coordinating with the Law Department, Public Affairs and other internal parties; and reporting on the incident and responses to the Security Oversight Committee.

The Incident Leader shall consult promptly with legal counsel to determine whether the Security Incident may expose ORGANIZATION to material legal penalties and/or liabilities. If there appears to be a material risk of such penalties or liabilities, the Incident Leader shall promptly ask the ISIRT to consider whether the investigation and reporting should be conducted through or under the oversight of legal counsel. External consultants, technical experts and/or legal counsel may be retained for purposes of incident response upon authorization by the ISIRT.

During a Critical Security Incident response the ISIRT members will meet in a predetermined physical location, by teleconference and/or by electronic communication to ensure that all members are informed of their duties and tasks in connection to the response, and to avoid duplication of effort and loss of evidence.

7.4 Moderate and Minor Incidents

An Incident Investigator will be designated for each Moderate or Minor Security Incident. The Incident Investigator shall be provided with any additional investigative or analytical help which may be necessary or desirable by the Security Team. External resources may be obtained by authorization by the ISIRT. Moderate and Minor Security Incidents shall be reported periodically to the ISIRT under procedures adopted by the ISIRT.

7.5 Security Incident Forensic Investigation.

The Incident Leader or Incident Investigator will supervise and work with Security Team analysts and investigators to determine the extent of damage and the effects of the Security Incident on systems, data, and operations, as well as the threats and vulnerabilities which caused or facilitated the occurrence of the incident.

Information gathered in the investigation of Security Incidents shall be developed and preserved to the greatest extent possible as potential evidence admissible in court in case it is needed in legal proceedings. Whenever possible, any individuals or entities which may be liable for harm caused by the incident shall be identified, and the ISIRT may seek to have damages quantified for possible use in administrative or legal proceedings.

7.6 Suspicious Activities.

ORGANIZATION Workforce and Contractors will report Suspicious Activities to the Security Team, which will publish contact information and maintain reporting functions for such reporting.

The Security Team will investigate any such report appropriately, including followup interviews and log and audit trail reviews.

7.7 Audit Logs.

The Security Team will be responsible for reviewing audit trails and logs throughout the Information Systems. Such reviews will be conducted with respect to a given device or application whenever a Security Incident or Suspicious Activities are reported which may involve unauthorized access to the device or application.

The Security Team shall also review all audit trails and logs pertaining to Critical Systems no less frequently than _____________, and shall review samples of audit trails and logs pertaining to non-Critical Systems no less frequently than ___________, for possible evidence of Security Incidents or Suspicious Activities.

Review may be expedited by use of appropriate analysis tools. Scheduling and sampling procedures shall not be disclosed in advance to personnel not directly involved in the review. Information and observations obtained in the course of Security Team investigations and reviews shall be immediately assessed for indications of the reasonable possibility of the actual or threatened occurrence of a Security Incident or Incidents, using the prudent professional judgment of Security Team staff.

In the event Security Team staff determines that there is a reasonable possibility of an actual or threatened Security Incident they will report this determination to the ISIRT, which will respond in accordance with this Policy. A Security Team determination that upon investigation or review there is not a reasonable possibility of an actual or threatened Security Incident shall be logged and include in the Security Team’s report to the CISO.

7.8 Security Incident Response Times.

Upon receipt of information indicating the possible occurrence of a Security Incident, the ISIRT shall assign a preliminary rank to the Security Incident and proceed under the following timetable:

Critical Incidents:

Assign Incident Leader within _____

Control access to all relevant devices and records within _____

Notify ISIRT members within _________

Commence investigation within __________

First report to ISIRT on probable scope of harm and continuing risk within _____

Moderate:

Assign Incident Investigator within _________

Commence review of all relevant devices and records within ________

Report on probable scope of harm and continuing risk to Information Asset Supervisor within __

Minor:

Assign Incident Investigator within _________

Commence review of all relevant devices and records within ________

Report on probable scope of harm and continuing risk to Information Asset Supervisor within __

Suspicious Activity:

Security Team conducts preliminary review within ________

Security Team review of applicable logs/audit trails within ___________

Security Team interview(s) with relevant personnel within ________

Security Team determination whether to refer to ISIRT within ________

8. Cross-References

Acceptable Use Policy, Policy No. __

Authorized Security Officers: The authority of the Chief Information Security Officer ("CISO") and other accountable security personnel are set forth in Policy No. __

Policies and Procedures Documentation, Policy No. __

Security Team: The responsibility, authority and organizational structure of the Security Team is set forth in Policy No. __

"Accountable Security Personnel" is defined in Policy No. __

Contractor" is defined in Policy No. __

"Information System" is defined in Policy No. __

"Information Asset Supervisor" is defined in Policy No. __

"Protected Information" is defined in Policy No. __

"Workforce" is defined in Policy No. __

Why This Blog?

2007-01-28T14:47:00.000-08:00

I started this blog to try to help move information security theory and practice forward as both an intellectual discipline and professional practice area. Information security as a discipline is very new, as are the technologies involved and the professional disciplines of computer science, network implementation, and information management upon which information security builds. And computers and networks have evolved rapidly, which has required information security theory and practice to evolve rapidly in an attempt to keep pace.

Because all American statutory, regulatory, and common law is based at least to some extent on experience (and preferably on precedent), information security legal theory is not well-developed. As a result, no settled standards exist for allocating losses and settling disputes when security fails. In many cases nobody really knows how to determine whether someone has been negligent or has failed to meet regulatory requirements; sometimes, it is difficult to determine even what those duties are. Therefore, a legal theory of information security can’t just summarize existing legislation, precedent, and secondary authorities—it must weave together relevant strands of activity and thought.

This is what I want to try to do in this blog, I hope with my readers' help. I've been working on this for some years now, and it's a fascinating and I hope ultimately useful exercise. I plan to post, as and when I can, on not only current events and issues of interest to information security compliance and risk management, but also on some of the history of this field. I think this history has been neglected, to our disadvantage - we've learned a few things already, and it's worth it to try to remember them, even as we invent new tricks to deal with new problems.

The Integrated Information Security Standard of Care?

2007-01-26T16:32:00.000-08:00

That's what I call this. It's more fully justified and explained in Christiansen, An Integrated Standard of Care for Healthcare Information Security (2005):

Integrated Information Security Standard of Care

1. An information security duty of care exists when an entity:

a. Uses an information system to create, store, process or transmit information, and

b. The entity is required by law to protect that information against unauthorized disclosure, use, or alteration (i.e., it is protected information).

2. An entity is “required by law” to protect information when such a duty is established by:

a. A statutory, regulatory or contractual provision; or

b. The existence of a legal obligation of the entity to act for the benefit of a party who may be harmed by the unauthorized disclosure, use, or alteration of the protected information.

3. The information security duty of care is satisfied by the implementation of an information security program consisting of:

a. Organizational policies governing the use or disclosure, and/or the protection of the confidentiality, integrity and/or availability of protected information, and/or accountability for transactions or events affecting he confidentiality, integrity and/or availability of protected information, which are consistent with the requirements of applicable law.

b. Information system program policies, procedures, practices, and governance structures (controls) which:implement the foregoing organizational policies, and whose objective is to provide reasonable assurance that the information system is operated and functions so that:

(i) No disclosure or use of protected information is made by an individual, application, or device, unless that disclosure or use is authorized by organizational policy,

(ii) Protected information is reasonably available to individuals, applications, and/or devices in order to serve an authorized purpose under organizational policy, and

(iii) Protected information is not altered by an individual, application, and/or device except as authorized under organizational policy.

c. Administrative, physical, and technical information safeguards which are implemented as part of the information system program and are intended to provide reasonable protection against reasonably identifiable threats to protected information.

4. The controls and safeguards implemented for purposes of an information security program meet the standard of care if:

a. They provide a reasonable assurance of compliance with applicable organizational policies.

b. They are reasonably consistent with the controls and safeguards implemented by reasonably comparable entities using reasonably comparable information systems (peer organizations), unless

(i) The controls and/or safeguards implemented by peer organization fail to take into account known threats that can be readily addressed by reasonably available controls or safeguards, or

(ii) The operating environments and/or operational objectives of peer organizations differ materially from those of the implementing organization; and

c. The costs and burdens of the controls and safeguards are reasonably proportionate to the risks of harm to parties (with legal interests in protected information) that are created by use of the information system for the purposes, or under the conditions, that create such risks.

Of course, this standard doesn't just apply to healthcare.

Thinking About Risk: What Do You Know, and How Do You Know You Know It?

2007-01-26T12:37:00.000-08:00

I've been thinking a lot about IT risk issues for the last several years years, and one thing that is becoming clear is that IT security issues are only one category of IT risk. It is also pretty clear to me that we need a deeper and more robust discussion of what IT "risk" is, and how we work with it.

There is a lot of useful work going on in this area, and a lot of groundwork has been laid. (Examples: NIST and CERT specific to IT security; CobiT on IT in general; COSO on enterprise risk; Schneier; etc.) But some of the most insightful stuff I've seen has come out of the environmental sector - I've incorporated a lot of that into my own book.

I found one of the best and most illuminating examples of this in my recreational reading of Jared Diamond's *Collapse*, an analysis of how a number of societies succeeded or failed in dealing with environmental challenges. They range from Easter Island (big failure) to Tokugawa Japan (success). One part I found particularly striking and possibly quite valuable in thinking about IT risk issues was Diamond's "road map of factors contributing to failures of group decision-making."

I would characterize these as "cognitive" risk factors, which can work synergistically with technological, social, financial and other types of threats and vulnerabilities ("circumstantial risk factors?") to make a bad situation worse. I think these cognitive factors are at least intuitively pretty well known, but Diamond summarizes them (and demonstrates their effects) particularly well. I'm going to summarize them, and try to identify the kinds of IT risk situation where each type appears to be a contributing factor.

Diamond's "road map of factors" breaks down into the following four principal categories and their subcategories:

Factor 1. Failure to anticipate a problem before it arrives.

1.1 The group has never experienced the problem.
1.2 The group experienced the problem before but it was a long time ago and there is no accurate recollection.
1.3 Reasoning by false analogy: The problem looks like but in fact is not the same as one experienced before.

Factor 1 IT Comparison: I think it's fair to say that computer and electronic communication technologies don't work like anything human beings have dealt with before. (If they had computers in Atlantis obviously we don't remember!) And physical world analogies tend not to work very well in thinking about IT problems - look at some of the discussions about IP, jurisdictional and privacy issues. (I wrote a piece some years back arguing that "property" concepts implicitly based on physical world analogies break down in healthcare IT network environments.)

Factor 2: Failure to perceive a problem which has arrived.

2.1 "The origins of some problems are literally imperceptible" - the group doesn't have any way to see them developing.
2.2 The problem of "distant managers:" those responsible for making decisions are not on the scene where the problem is manifest, and so don't see it or don't perceive it accurately.
2.3 The problem develops in a "slow trend concealed by wide up-and-down fluctuations." This can lead to "creeping normalcy," in which harmful conditions develop so slowly that they are not really seen (the mythical "lobster gradually boiled to death").

Factor 2 IT Comparison: Legion. The "imperceptible origins" of some problems might include the way that some applications interact to create new, unanticipated vulnerabilties. And probably every CSO I know would say s/he suffers or has suffered from "distant managers" - maybe not physically, but "distanced" from the realities of their security problems. (Also part of the problem with DHS and its take on cybersecurity?) And how about the "creeping normalcy" of an Internet environment full of spam, phishing and other vermin?

Factor 3: "The most frequent and most surprising factor," the failure to "even attempt to solve a problem once it has been perceived." The reasons for this factor are "rational" and "irrational."

The "rational" reasons for not solving problems basically amount to variants on selfishness (or at least less-than-enlightened self-interest), i.e. advancing individual or small-group interests at the expense of a larger group or the community. If the small group or individual receives a large benefit at the expense of "small harms" to each of the members of the large group or community, the small group will have a strong motivation to pursue the benefit, while no individual member of the community will have much motivation to try to stop the harmful activity.
3.1 "ISEP" - "it's someone else's problem" - externalizing the harms caused by your activities onto others or the community as a whole.
3.2 "The tragedy of the commons" (a popular one when I was in college): A consequence of the adoption of rational selfishness by all users of a common, limited resource. If one user starts taking more than his share, all users have an incentive to try to get in there and take more than their shares first.
The resource is degraded or lost.
3.3 "Elite conflict of interest." Another variant, where decisions for the community are made by an elite which pursues its own selfish interests at the expense of the community.

Rational Factors 3.1 - 3.3 IT Comparison: Again legion. Vendors selling insecure products ("it's the users' problem"), spammers degrading the Internet commons, elite executive groups underspending on mission functions to enhance their compensation, consultants "hiding the ball" on crucial information to preserve a work stream, etc., etc.

3.4 "Irrational" attachment to inappropriate values - the actions needed for a solution are somehow inconsistent with the group's priorities or mission. Sometimes a difficult matter to judge, since it may be hard to see why values which led to success before won't work in the future, and it may be hard to predict whether new values will in fact work.
3.5 "Irrational" crowd psychology - doing what everybody else does because they are doing it.
3.5 "Irrational" group-think: suppression of doubts and dissent, premature consensus, shared but erroneous assumptions.
3.6 Denial - 'nuff said?

Irrational Factors 3.4 - 3.6 IT Comparison: On the values side think about corporate cultural/brand identities - Big Blue v. Microsoft on the future of PCs, Microsoft v. open source on the future of software, etc. Crowd psychology - anybody still holding dot.coms stock options? Group-think: dot.com investment gurus? (Maybe that was an elite conflict of interest problem . . . ) Denial - how high was the Dow supposed to go, again???

Factor 4: The problem may be beyond the group's capacity to solve, may be prohibitively expensive to solve, or the problem may be so far advanced that any solution is too little/too late.

Factor 4 IT Comparison: This is the ideal world of risk management. If we can get past Factors 1 - 3, all we need to do is figure out if we can solve the problem or not, and how much it will cost!

Concluding Note: None of this is altogether new - for example, the CobiT "IT Governance Maturity Model" I think is based on a recognition of these kinds of problem, and gives a pretty good structure for their avoidance. The same is true for more general identification and management in the COSO Enterprise Risk Management Framework. But Diamond's scheme was especially striking because it seemed so clearly applicable to issues and problems I have seen over the last several years in many IT settings, even though based on a completely different field of study.

I guess the lesson I take from this (one lesson, anyway, so far) is that organizations (like the societies Diamond studied) can be cognitively more or less competent, and that these cognitive factors need to be front and center in any really thorough risk assessment. This is probably not a comfortable thing to suggest in many settings, since it means broadening the focus from technology- and business process-specific threats and vulnerabilities to include management and governance - a bigger project and a harder and more threatening sell to management.

But I think ultimately this is where IT security risk analysis and management has to go, not just for the sake of compliance but for the sake (in some cases) of the sustainability of the organization. An IT-dependent organization had better be good at understanding and managing its IT - and we need to recognize that this kind of cognitive competence is itself a risk factor which should be assessed and managed in its own right.