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!
Thursday, September 30, 2010
Thursday, July 8, 2010
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
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.
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.
Thursday, December 17, 2009
HITECH Incorporation by Law: A Painful Conundrum
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.)
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.)
Tuesday, November 24, 2009
Upcoming HIPAA Business Associate Presentations
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?
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
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!
Thanks!
Friday, November 20, 2009
How to Eliminate the Barriers to Health Information Exchange
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.)
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.)
Saturday, November 14, 2009
More HIPAA/HITECH and Joint IT Environments: Multiple Account Access
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.)
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.)
Friday, November 13, 2009
HITECH/HIPAA Obligations of Cloud Services Providers
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.
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.
Tuesday, October 27, 2009
HITECH and Business Associate Compliance - The Key Points
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?
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?
Subscribe to:
Posts (Atom)
