HITECH Megarule Planning Tips

As of this post, we still don’t know the status of the HITECH Megarule. Publication was most recently scheduled for June 22, but on June 26 the Office of Management and Budget (“OMB) announced an extension of its review period for the regulations, for an unspecified period. (OMB review is mandatory before final publication.) OMB review can only ber extended (1) by OMB, for thirty days, or (2) by request of the issuing agency, for an indefinite period. Since we are now well past the thirty day mark, this was evidently an extension requested by HHS.

We don’t know the reasons for the extension or when to really expect the Megarule. I’ve heard speculation that publication is being held up til after the election for political reasons, and while I like political speculation as much as the next person (probably more than most), and really would prefer that an important set of regulations like these not get caught up in pre-election political posturing (which seems likely for any public policy initiative at this point), my own suspicion is that it is simply that this is a complex, important set of rules, addressing some issues subject to genuine  good-faith dispute, and it is taking a long time to get them hashed out. The point ultimately being, they could come out at any time, and I do expect them by the end of the year.

Given the scope and implications of the Megarule, this is not actually much time, and I recommend starting the planning process now (or re-starting it, if you started it back when the regulations were originally scheduled to be published, and put it on hold when they were not). In particular, I recommend the following steps be included in whatever compliance process an organization adopts:

• Fiduciary Officer and Key Staff Briefing and Reporting.

Compliance with HIPAA (and therefore HITECH) is an organizational obligation which must be subject to fiduciary oversight. Failure to implement such oversight can lead to avoidable or enhanced civil penalties, and under the wrong circumstances could even expose an organization to criminal liability for uncontrolled, unauthorized employee or agent actions, and potentially expose fiduciaries to personal liability for failure to exercise prudent judgment on behalf of the organization. On a more positive note, when reporting is working well and the right officers are kept in the loop, compliance decisions are likely to be better informed and more appropriate for the organization, necessary funding and other resources may be more available, and resistance to compliance activities and requirements will be lessened if executive support is clear.

• Compliance Component Identification or Confirmation.

Many Covered Entities and Business Associates may be usefully analyzed as an entity performing multiple HIPAA covered functions, or a “hybrid entity.” Under HIPAA, a Covered Entity which performs multiple covered functions is required to have controls to ensure that PHI is only used for the purpose for which it was obtained. HIPAA then elaborates this requirement in the concept of a hybrid entity, in which a single legal entity has business activities which include both functions covered by HIPAA, and functions which are not. A hybrid entity can then designate “health care components” (I prefer “covered component”) which perform HIPAA-covered functions, and only those components are required to comply.

For smaller or very simple organizations this kind of designation may be very simple, but in my opinion it is necessary in any case if only to comply with the minimum necessary rule and Protected Health Information access control requirements; even in the smallest office, for example, the receptionist probably doesn’t need to know patient diagnoses to perform his job, while in larger organizations compliance officers or auditors may sometimes have a legitimate need to access Protected Health Information to do their jobs but not for other purposes. Documenting this kind of functional distinction is not only a good idea, it is a requirement of the minimum necessary rule, and is really the basis for the designation of covered components in any organization.

The HIPAA requirements for Covered Entities performing multiple covered functions and the concept of the “hybrid entity” currently apply only to Covered Entities, but I expect that it will be applicable to Business Associates as well once the HITECH Megarule is effective. I have already used the concepts a number of times to help Business Associates manage Business Associate Contract compliance, and in a couple of cases to begin HITECH compliance planning.

Covered component designation requires documentation of the designation, and controls to ensure that Protected Health Information is only used or disclosed within the designated component, in the case of a Business Associate as limited by the applicable Business Associate Contract. Other components of the organization may perform functions for the covered component, in principle as if they were unrelated entities under contract. Because “designation” is a matter of documentation and controls such a designation would not mean that different components cannot share the same resources or staff, or be subject to the same oversight structure. It does mean, however, that there may need to be operational controls which enforce the designations, for example clear policies regarding assignment of staff.

• Contract Management Review.While we do anticipate a phase-in Business Associate Contract period, with some “grandfathering” of contracts permitted, HITECH compliance will clearly require all Business Associate Contracts to be amended and updated. This is likely to be a daunting project for almost all Covered Entities and Business Associates, and I strongly recommend getting ready for it.

This is a fundamental compliance issue, since the contracts underlying Business Associate Contracts define the permitted (and conversely prohibited) uses and disclosures of Protected Health Information. The “upstream” contractor defines what is permitted; the “downstream” contractee agrees to be bound by those limitations. If the “upstream” contractor defines the limits too broadly, it risks violating the minimum necessary rule; if the “downstream” contractee fails to stay within those limits, it violates the Business Associate Contract, and once it is effective probably the HITECH Megarule as well.

If you’ve been reading carefully, by the say, you’ve noticed that I introduced the concept of “upstream” and “downstream” contracting, which you probably don’t recognize from other HIPAA/HITECH discussions. There’s a good reason for that, and another good reason for addressing contract management preparation now:  If the final Megarule follows the draft HITECH Business Associates rule, Business Associate status will “follow the PHI.” That is, subcontractors of Business Associates which work with Protected Health Information on behalf of the Business Associate (which is permitting the subcontractor to do so on behalf of a Covered Entity) are themselves Business Associates – and so are their subcontrators. And so are the subcontractors  of the subcontractors, and so on. And in each set of relationships a Business Associate Contract will be required. So, I find it useful to talk about Business Associate Contract issues under HITECH in terms of “upstream” contractor entities, which contract for and define the limitations on services involving the use or disclosure of Protected Health Information, and “downstream” contractee entities, which accept those contracts and limitations.

Clearly all of this is going to require a lot of contract management and renegotiation, for Covered Entities, Business Associates, and current subcontractors alike. I therefore think it would be a very good idea for such organizations to conduct  a contract inventory to ensure all Business Associate Contracts are identified – upstream and down, as applicable – as are the permitted uses and disclosures applicable for each, and any applicable subcontractors. Existing forms of contract should be reviewed and draft revisions started, to facilitate ultimate revision when the Megarule is published. Contact information for counter-parties should be updated, and for important relationships it is really not too early to begin discussions about the transition to the brave new world of HITECH compliance.

•  HITECH Compliance Planning.

While it would be premature to try to develop HITECH compliant policies and procedurees before the Megarule is published, it is not too early to begin planning the processes which wil be needed to develop and implement them when it is.

A good place to start is with a HITECH gap analysis. I have already developed one, since I’ve had significant demand for it, and this kind of analysis would then be the basis for any remedial action needed once the Megarule is published. While I don’t think any such tool can be 100% on point for the Megarule, I think it is possible to anticipate at least 90% of the final requirements – at least for purposes of a checklist inventory – and if used properly will also serve as a reference tool identifying existing policy, procedural and related documentation, to make it easier to update and amend as needed.

Of course, actual compliance implementation will require assigned duties and authority to conduct gap analyses, contract review, and policies and procedures revisions and the like, and I don’t think it would be premature to identify such assignments and get appropriate staff and/or contractors started on gap analyses and compliance planning. And keep in mind, this loops back to just to loop back to the first task, fiduciary reporting and oversight.

While we don’t have any certainty as to the date the Megarule will be published, we are pretty sure it will be soon, and we can be certain it will require substantial work. Some planning now could help prevent a lot more pain later.