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!
Monday, March 2, 2009
Monday, April 28, 2008
How Do You Amend Your Terms of Use? Hint: Don't Hide the Ball.
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.
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.
Monday, April 21, 2008
I Seem to be a Spime: Why Nobody Wants EHRs and PHRs
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!
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!
Saturday, April 28, 2007
Data Havens and UFO Hacking
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.
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.
Tuesday, April 3, 2007
Newbie Lawyers as Enablers of Bad Security
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!
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!
Sunday, March 25, 2007
Self-Help on the Internet: Is the Best Defense Really a Good Offense?
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.
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.
Wednesday, March 14, 2007
Organizational Governance and Risk Acceptance
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.
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.
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.
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.
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.
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)
Subscribe to:
Posts (Atom)
