Web-Tones

HIPAA Regs Full Text Now "Clickable!"

The HIPAA Survival Guide (HSG) online now has the full text of the HIPAA Regulations available in a "clickable" format. What does that mean? You can think of it as a point and click navigation for the regulations in a Wikipedia like format. Each time another section of the regulations is referenced in the section you are reading you can "point and click" to the referenced section.

Now that the HITECH Act's meaningful use definition makes compliance with HIPAA mandatory (i.e. if a provider or facility wants to get paid their EHR incentives) many more stakeholders will need to become HIPAA literate. The HSG makes the education process easier by making the regulations more visible and "digestible."

Don't get me wrong, if you want to become literate you still need to do the work, but you don't have to crawl through paper documents or 100 page PDF files. If you want to learn more about the background of the HSG click here.

Check out a FREE EHR Checklist. If you would like stay current on HSG updates then sign up for our FREE HITECH/HIPAA Compliance Newsletter.

HITECH / HIPAA: The Security Rule Dissected (Part 2)

Part 1 of this series introduced the HIPAA Security Rule ("SR" or "Rule") but did not get into its substantive requirements. This post will review the SR's Administrative Safeguards. Subsequent posts will cover the remaining safeguards and the major sections of the Rule as depicted in the graphic below. The "Risk Analysis & Risk Management" component is actually part of the Administrative Safeguards but is also reviewed separately due to its criticality.

The objective of this series is not to provide an exhaustive review of the SR, but rather to get those unfamiliar with its requirements grounded. One important thing to keep in mind is that the SR is a great example of the convergence between policy, law and technology.

These three fundamental underpinnings of the Rule must be examined holistically. If a provider or facility focuses on the HIT component standing alone (as some technology vendors may tend to encourage) then other non-technology aspects of the rule, which have policy/legal implications, may be missed entirely.

Introduction

The SR is made up of CFR Part 160 (Subpart A) and Part 164 (Subpart C). The principal objectives of the Rule, as it pertains to a covered entity are as follows (160.304(a)):

1. Ensure the confidentiality, integrity, and availability of all its ePHI.
2. Protect against any reasonably anticipated threats or hazards of its ePHI.
3. Protect against any reasonably anticipated uses or disclosures of ePHI not permitted or required under the Privacy Rule ("PR").
4. Ensure its workforce complies with the SR.

The items above do not appear unreasonable or overly burdensome. However, the devil (as always) lies in the details of the specifications, some of which are absolutely mandatory while others are labeled "Addressable." The Rule also contains a concept called the "Flexibility Approach;" what others refer to as the Rule's guiding principle. In essence, the flexibility principle enumerates four factors that a covered entity ("CE") should consider when deciding how to "reasonably and appropriately" implement the standards and implementation specifications. The four factors are as follows:

1. The size, complexity, and capabilities of the CE.
2. The CE's technical infrastructure, hardware, and software security capabilities.
3. The costs of security measures.
4. The probability and criticality of potential risks to ePHI.

In short, there appears to be some "wiggle room" in the SR, especially for small providers. However, as will be discussed throughout this series, not as much as one might think when the SR is viewed in its entirety. The rule is made up of standards and their respective implementation specifications.

A CE must comply with the standards; period, end of story. The implementation specifications is where the "wiggle room" lies (what there is of it).Specifications are either "Required" or "Addressable." Required specifications must be implemented. Addressable specifications must be assessed and implemented as specified if reasonable and appropriate to the CE. If not reasonable and appropriate, the reason it is not must be documented and an equivalent alternative measure must be implemented if the alternative is "reasonable and appropriate."

In short, all specifications must be dealt with in some way, shape, or form, by all providers. The flexibility approach may ease the burden for small providers, but no substantive requirements are eliminated. At a minimum a small provider will need a compelling justification if an addressable specification is not implemented.

The Administrative Safeguards

The Administrative Safeguards ("AS") are contained in section 164.308. The AS contains eight (8) "technical" standards with eighteen corresponding implementation specifications, some of which are Required and others that are Addressable (164.308(a)) The AS also contains one (1) "business" standard (164.308(b)). The AS comprises over 50% of the SR.

164.308(a): The AS "Technical" Standards

The eight standards are as follows:

   1. Standard: Security management process. Implement policies and procedures to prevent, detect, contain, and correct security violations.

   2. Standard: Assigned security responsibility. Identify the security official who is responsible for the development and implementation of the policies and procedures required by this subpart for the entity.

   3. Standard: Workforce security. Implement policies and procedures to ensure that only appropriate members of the workforce have access to ePHI.

   4. Standard: Information access management. Implement policies and procedures for authorized access to ePHI that are consistent with the applicable requirements of the PR.

   5. Standard: Security awareness and training. Implement a security awareness and training program for all members of its workforce (including management).

   6. Standard: Security incident procedures. Implement policies and procedures to address security incidents.

   7. Standard: Contingency plan. Establish (and implement as needed) policies and procedures for responding to an emergency or other occurrence (for example, fire, vandalism, system failure, and natural disaster) that could damage systems that contain ePHI.

   8. Standard: Evaluation. Perform a periodic technical and non-technical evaluation to ensure that standards continue to be met in response to operational and environmental changes.

164.308(b): The"AS" Business Standard

Standard: Business associate contracts and other arrangements. A CE, in accordance with the general rule (§164.306), may permit a business associate ("BA") to create, receive, maintain, or transmit ePHI on the CE's behalf only if the CE obtains satisfactory assurances, in accordance with the Rule (164.314(a)) that the BA will appropriately safeguard the information. These assurances must be obtained by way of a written contract (or other arrangement) that meets the requirements of the Rule.

It should be noted and re-emphasized that a contract between the CE and BA must contain certain language in order to meet the requirements of the Rule (e.g. a "simple" contract that only states that the BA will protect the CE's ePHI is not sufficient). Furthermore, the HITECH Act now imposes stricter requirements on a BA and contains language that significantly increases the number BAs that a CE may need to interact with.Therefore, it is recommended that all existing BA contracts be reviewed, and where appropriate, re-drafted to conform to HITECH requirements.

Summary & Additional Resources

Process centric: Readers should note that the AS contains standards that are process centric. There is no commercial-off-the-shelf (COTS) technology solution that can be purchased that will satisfy these requirements.However, there are templates and other reusable collateral that can help "jump start" the effort.We chose to use the words "Technical" and "Business" to differentiate the types of processes that must be implemented and documented.

Regulators will likely insist on seeing demonstrable evidence that a provider or facility has "attacked" these standards with a degree of rigor. Demonstrable evidence means significantly more than just having the necessary documentation available, it requires proof that the required processes have been implemented and are being used to achieve the desired effect. In other words, do not confuse "documented" with "implemented." These are two distinct concepts and both are required.

Standard: Security management process. While all the AS standards must be met, the first is arguably the most important and will be further explored in the "Risk Analysis & Risk Management" part of this series. This standard has four Required implementation specifications: 1) Risk analysis, 2) Risk management, 3) Sanction policy, and 4) Information system activity review.

The first two of these specifications are quite broad in scope. An in depth review of this standard (and its corresponding specifications) will be provided as an example of the process by which the requirements of the other AS standards can be met. It will be difficult (to say the lest) to meet HHS' meaningful use definition if a provider or facility has: a) not addressed the AS standards at a minimum; and b) does not have a plan in place for meeting all of the SR requirements, and it should go without saying, the requirements of the PR as well.

Electronic vs. oral and paper: It is important to note that the Privacy Rule applies to all forms of patients’ protected health information, whether electronic, written, or oral. In contrast, the Security Rule covers only protected health information that is in electronic form. This includes ePHI that is created, received, maintained or transmitted. For example, ePHI may be transmitted over the Internet, stored on a computer, a CD, a disk, magnetic tape, or other related means. The Security Rule does not cover PHI that is transmitted or stored on paper or provided orally.

Additional Resources

If readers are looking for additional regulatory information regarding HIPAA's Security Rule then the  HHS Security Standard Portal is the place to start. Readers should take special note of the HIPAA Security Educational Paper Series. The Educational Series contains a number of PDF documents that correspond to major sections of the Security Rule.

Part 3 of this series can be found here. Check out a FREE EHR Checklist. If you would like more information regarding EHR implementations, and related compliance issues, sign up for our FREE HITECH/HIPAA Compliance Newsletter.

HITECH / HIPAA: The Security Rule Dissected (Part 1)

This series of posts will look at key aspects of the HIPAA Security Rule. Now that the HITECH Act has put the HIPAA Privacy and Security Rules once again front and center, a much larger number of organizational stakeholders will need to become better acquainted with their basic tenets.

From a healthcare business perspective, a better understanding of the rules is mission critical since compliance with the rules is now an integral part of HHS' meaningful use definition. In other words, non-compliance means that a provider or facility may not get paid their EHR incentives.

Whereas the HIPAA Privacy Rule ("PR") deals with protected health information ("PHI") in general, the HIPAA Security Rule ("SR") deals with electronic PHI (ePHI), which is essentially a subset of what the PR encompasses. In terms of actual regulatory text the SR only spans approximately eight (8) pages, which is the good news. The bad news is the SR is highly technical in nature. For all intents and purposes this rule is the codification of certain information technology standards and best practices.

Broadly speaking, the SR requires implementation of three types of safeguards: 1) administrative, 2) physical, and 3) technical. In addition, it imposes other organizational requirements and a need to document processes analogous to the PR. That said, creating the necessary SR documentation will likely prove significantly more "vexing" than its PR counterpart, especially for small providers.

The SR has been in effect since April 20, 2005. However, because the majority of providers and facilities have not yet made the move to electronic health records (EHRs), it has largely been ignored. The Obama administration's push for EHRs, under the HITECH Act, has set in motion a regulatory freight train that most in the healthcare industry are more or less oblivious to, although the word is slowly starting to get out.

This series of post is intended to provide insights into the SR that will allow a provider or facility to acquire a fundamental understanding of the compliance requirements contained within rule; where appropriate, additional reference information will be linked to that most readers should find quite useful. The HIPAA Privacy Rule will be dissected in a separate series of posts.

Part 2 of this series can be found here.  Check out a FREE EHR Checklist.  If you would like more information regarding EHR implementations, and related compliance issues, sign up for our FREE HITECH/HIPAA Compliance Newsletter.

The Problem with Health Care Standards?

The Health Care Blog: Should Health Care Standards be Open Source?.This post from the THCB does an excellent job of identifying one of the problems (perhaps the core problem) with health care standards, that  is that they are closed (i.e. not free and open source for the most part). I am not talking about EHR software (or any other kinds of health care software), I literally mean the standards themselves, developed by various standards development organizations (SDO's).

Why? Because just about everything within the health care industry is closed. That is an indication of just how powerful the incumbents are across the board (providers, hospitals, insurance companies, software vendors, standards organizations, you name it). It is a dysfunctional marketplace precisely because it controlled by a relatively few. There is no real competition and that hasn't changed in fifty years because for the most part, the incumbents like the status quo. Who can blame them?

The industry will never be transformed from the inside. It is one of America's great remaining oligopolies. At a minimum, if we are going to make any progress at all with respect to interoperability then we need open standards. Period. Does anyone believe for a moment that the technology industry would have advanced according to Moore's Law without open standards? NO WAY. In the technology industry we have seen quality go up and prices come down. What about the health care industry? I will let you answer that question for yourself.

Health Care Reform: Lead, Follow, or Get Out of the Way!

I usually do not jump into policy wonk discussions about heathcare reform. Why? Because on the broader issue of reform I do not have much to add to the conversation. However, I do KNOW that our current system is broken beyond belief and therefore, the status quo is simply not an acceptable/viable option. To see an entertaining "back of the napkin view" refer to this post. So this is a purely personal post. If you do not agree with my position regarding the status quo then this is a good place to stop reading.

One side of this debate apparently wants to do nothing, and wants to use the worst kind of demagoguery to achieve their status quo objective . They see it purely as a political fight that must be won at all costs. Sure, go ahead and use hate (which is likely to lead to violence) to achieve your political agenda. We have seen this movie before in American politics and it doesn't have a nice ending. Why not engage in a civil and constructive manner instead? In the marketplace of ideas there is lots of room.

We need to put aside this "do nothing" BS and decide to do something for the sake of our children and our grandchildren, and ultimately for our own sakes as well. Doing something is not only the morally right thing to, it is economically the right thing to do. In short, doing nothing only serves the interest of the few at the expense of the many. It is a completely unsustainable alternative.

In the Appendix of the HIPAA Survival Guide we close with the following:

It is through grace, divine mercy, and the awesome power of the almighty that a sick nation will become well again. We all have a role to play, but it will take a firm belief in something greater than ourselves to reach this objective. Future generations are relying on us to do the work and keep the faith.

In short, health care reform matters. It may be the single most important domestic political agenda item of our generation. It is simply unconscionable to remain on the sidelines and not to engage. However, whatever your religious beliefs, engaging in the conversation need not, and must not, be seen as an opportunity to engage by fanning the flames of hatred.

What purpose does that serve?

Healthcare Providers Online: Legal Perils for the Uninitiated?

Many healthcare providers are starting to make the move online. That is really not surprising because the move, like every other industry, appears inevitable. Here's a recent example from EMR Daily News (which BTW, is an excellent blog and one that you should be reading).

Providers that were once tepid about the move online are now going to be in a hurry to get there, since they will see the advantages that more nimble colleagues are obtaining, like the small matter of getting paid their EHR incentives.

As this last link notes however, many providers are unaware of the legal compliance issues that they may face as they go online. Here's the money quote from the link:

"That brings me to the point of this post, something that very few healthcare providers are aware of: section 164.520(c)(3) of HIPAA's Privacy Rule states as follows (paraphrasing):

Specific requirements for electronic notice. A covered entity (CE) that maintains a website must make the notice prominently available on its website. A CE may provide notice via email if the individual has agreed to such notice and other requirements of this section are met."

The reference above is to a provider's HIPAA Privacy Notice and is NOT a reference to the typical privacy policies found on most websites. Of course a provider could place it there, but then the issue becomes whether or not the "prominently available" requirement has been met?

But there is more to the legal compliance story for providers than meeting the HIPAA requirements. Providers also need to be in compliance with all other applicable law that is pertinent to running an online business. For example, if a provider's site has a blog with open comments and the ability to attach user generated content (UGC), then a provider must comply with the Digital Millennium Copyright Act (DMCA) if they want to take advantage of its safe harbor.

The DMCA is the tip of the iceberg, depending on the type of site a provider launches. Providers and facilities are encouraged to read "Why Audit Your Website?" to get a better understanding of online legal issues. These legal issues, in some cases, apply "across the board" and are not industry specific.

Check out a FREE EHR Checklist. If you would like more information regarding EHR implementations, and related compliance issues, sign up for our FREE HITECH/HIPAA Compliance Newsletter.

HITECH/HIPAA Effective Dates & Commentary

You can find an excellent summary of the modifications to HIPAA mandated by the HITECH Act here. It is one of the more thorough summaries we have found to date, with Appendix A containing a calendar of HITECH/HIPAA due dates and effective dates.

This post will review the pertinent dates from the HITECH Act Subtitle D and provide commentary as appropriate:

Upon Enactment: February 17, 2009

• Application of tiered civil monetary penalties (i.e. for violations occuring post enactment)
• State Attorney General Authority to Enforce  (i.e. bring a civil action on behalf of citizens post enactment)

Note: Clearly this raises the stakes from day one. We don't know of any cases brought by a state AG as of yet (circa August 2009), but when it happens it is guaranteed to make the national news.

Within 60 Days of Enactment: April 20, 2009

• HHS must set forth a list of technologies and methodologies that render information "unusable, unreadable or indecipherable." Directly relevant to breach notification requirements.

Note: Notification of breach requirements were covered in this post. Section 13402 of HITECH's Subtitle D is the relevant section. HHS has provided the required guidance and therefore unsecured PHI now is defined (paraphrased and annotated) as follows:

13402(h): unsecured PHI* means PHI that is not secured through: 1) encryption; and/or 2) destruction—as provided by HHS guidance. Methods must render PHI “unusable, unreadable, or indecipherable” to unauthorized individuals (see HIPAA Security Rule  & NIST standards).

Within 180 Days of Enactment: August 18, 2009

• HHS and FTC must each promulgate interim final regulations on breach notification; which apply to breaches discovered on or after the interim final regulations have been published.

Note: Breach notification is covered in Section 13402 of HITECH's Subtitle D.

By this specific date: December 31, 2009

• HHS must adopt rules for the initial prioritized set of standards related to accounting for disclosures; with the regulations required to implement the standard due six (6) months after the standard has been adopted.

Note: the relevant Subtitle D Section is 13405.

Due Within One Year Post Enactment: February 18, 2010

• HHS and FTC study on privacy and security requirements for PHR vendors and applications
• GAO study on best practices for disclosures for treatment and use of electronic informed consent.
• First annual report on HIPAA enforcement.
• First annual guidance on the most effective and appropriate technical safeguards for health information.
• HHS study on de-identification.
• HHS implementation of health information privacy educational initiative.

Note: PHR (personal health records) vendors include companies like Google and Microsoft. These are "cloud computing" offerings that allow consumers/patients to track their own health information. EHR vendors are also offering cloud solutions as discussed here.

Effective One Year Post Enactment: February 18, 2010

• Application of rules to, and accountability for, business associates.
• Clarification regarding which entities are required to be business associates.
• Patient's right to restrict disclosures to health plans.
• Deeming of limited data set as satisfying the minimum necessary standard.
• Patient's right to electronic access to, and an electronic copy of, their health record.
• Clarification regarding marketing provisions.
• Opt-out for fund raising communications; HIPAA's current provisions regarding fund raising remain in full force an effect.
• Clarification regarding the ability to impose criminal penalties against individuals.
• Civil monetary penalties and settlements flowing to HHS/OCR (Office of Civil Rights) for enforcement.
• Requirement for HHS to begin conducting mandatory audits.

Note: The last two "bulleted" items are covered in Sections 13410 and 13411. Refer to this post for more information regarding improved enforcement (13410) and this one for mandatory audits (13411).

Within 24 Months of Enactment: February 18, 2011

• HHS to provide guidance regarding "minimum necessary."
• Promulgated regulations regarding prohibition on the sale of PHI data, which will be effective six (6) months post promulgation.
• GAO report on methodology for providing individuals with a percentage of HIPAA penalties.
• Promulgation on imposition of civil monetary penalties in cases of "willful neglect" and that HHS can pursue a civil action that would otherwise qualify as criminal.

Note: Individuals still cannot bring a civil action but clearly will now have more financial incentive to file a HIPAA complaint. The definition of "willful neglect" is still an open question. Refer to this post for commentary regarding same.

By this specific date: January 1, 2011

• Initial deadline for complying with new accounting for disclosure rules for entities implementing EHR systems post January 1, 2009.

Note: the relevant Subtitle D Section is 13405.

24 Months of Enactment: February 18, 2011

• Clarification of HHS' ability to pursue civil penalties when criminal penalties are not pursued; applies to violations discovered on or after.
• HHS' requirement to impose civil monetary penalties in cases of "willful neglect"; applies to violations discovered on or after.
  

Note: Given the lax enforcement of HIPAA's Privacy & Security Rules prior to the HITECH Act, I am certain that HHS is going to have no problem finding instances of "willful neglect"--especially for those unlucky few to be the first ones audited.

36 Months of Enactment: February 18, 2012

• HHS to promulgate methodology for providing individuals with a percentage of HIPAA penalties that OCR collects.

Note: It should be fairly clear that the HITECH Act has provided HHS with a money machine and individuals get to play for more than "funzies."

By this year: 2013

• Extended deadline for older systems to comply with the new accounting for disclosure rules.

Note: the relevant Subtitle D Section is 13405.

By this specific date: January 1, 2014

• Initial deadline for older systems to comply with the new accounting for disclosure rules.

Note: the relevant Subtitle D Section is 13405.

60 Months of Enactment: February 18, 2014

• GAO study on impact of American Recovery and Reinvestment Act (ARRA).

By this year: 2016

• Extended deadline for older systems to comply with the new accounting for disclosure rules.

Note: the relevant Subtitle D Section is 13405.

Check out a FREE EHR Checklist. If you would like more information regarding EHR implementations, and related compliance issues, sign up for our FREE HITECH/HIPAA Compliance Newsletter.

EHR & HITECH/HIPAA: Mother of Wicked Problems: Part VIII

Part VII of this series can be found here. Finally, we arrive at the end of this series of posts. However, if you are considering implementing an EHR and have already started thinking about HITECH/HIPAA compliance then this is the beginning of the process for you. This entire series of posts can be considered a "hit list" of things to reflect upon during an implementation project.

That said, the entire hit list converges on meaningful use, the final component of our diagram below, and we recommend that you seriously consider selecting meaningful use as the organizing principle of your project. Why? We believe there are many reasons for doing so, but these three are at the top of the list:

1. In order to get paid under the HITECH Act you must demonstrate: Meaningful Use of Certified EHR Technology.
2. The five policy priorities listed below are directly from HHS's meaningful use matrix (i.e. the objectives and care goals of HHS's definition for 2011, 2013 and 2015 are all categorized under a specific policy priority).
3. Why reinvent the wheel? Many (if not all) of the meaningful use requirements represent the thinking of healthcare's "best and brightest" over the last twenty years. These requirements should already be action items for providers and facilities that want to compete fiercely in the 21 century.

Check out a FREE EHR Checklist. If you would like more information regarding EHR implementations, and related compliance issues, sign up for our FREE HITECH/HIPAA Compliance Newsletter.

EHR & HITECH/HIPAA: Mother of Wicked Problems: Part VII

Part VI of this series can be found here. Most providers and facilities will find it extremely difficult to meet their EHR/compliance objectives without an effective partnering strategy. Why? For all the reasons that we have discussed during this series. There is simply far too much complexity for any one organization to go it alone. That said, there are some partners listed below that might not be considered "traditional."

Developing an effective partnering strategy involves, at its core, developing a set of trusted relationships. It might surprise you that regulators can be effective partners. How so? If you engage them early in the process and build rapport then many are willing to point you to available resources that might help simplify certain tasks. That's not to say that a regulator won't be rigorous in his/her enforcement, but rather it is simply human nature to lend more assistance to people we know and trust.

Likewise, trusted colleagues within the industry can be great partners. By and large, providers and facilities of similar sizes will be solving analogous problems. There is much to gain from sharing lessons learned early in the process. Unfortunately, the "yearly" conferences usually do not provide the necessary forum often enough for this type of sharing to be effective. However, the virtual tools are now mature enough that travel is not required. Learn to use the tools available to your advantage and build collaborative relationships with peers in the industry.

It is often difficult to discuss partnering concepts without sounding "pollyannaish." Who needs it? We all do. Our professional lives have become far too complex. Lastly, building effective partnerships is not "kids stuff," its hard work. Get busy.

Part VIII of this series can be found here.

Check out a FREE EHR Checklist. If you would like more information regarding EHR implementations, and related compliance issues, sign up for our FREE HITECH/HIPAA Compliance Newsletter.

EHR & HITECH/HIPAA: Mother of Wicked Problems: Part VI

Part V of this series can be found here. This post focuses on Internet resources and stresses the importance of leveraging what is available.

There are a significant number of high quality resources now available on the Internet. Some of the best information is starting to come from the Federal agencies themselves. HHS in particular has done an outstanding job of providing high quality content related to HIPAA compliance.

The following links are representative:

HHS Privacy Rule Portal

The following URL is the entry point to the HHS Health Information Privacy portal. If you are looking for regulatory information regarding HIPAA's Privacy rule this is where you should start.

HHS Health Information Privacy

HHS Security Rule Portal

The following URL is the entry point to the HHS Security Standard portal. If you are looking for regulatory information regarding HIPAA's Security rule this is where you should start.

HHS Overview Security Standard

Of special note on the page above is a link to the HIPAA Security Educational Paper Series.This series is must reading for your HIT staff.

A more expansive list of industry related sites can be found on the HIPAA Survival Guide's(HSG) resources page here. In future releases of the guide additional reference information will be made available and categorized by a "to be developed" taxonomy.

The problem now is not the availability of high quality content but rather that there is too much of it, and therefore raw search technology only goes so far in addressing the needle in the haystack problem.The intent of HSG's resources page(s) is to provide enough reference links on a given topic to get the reader pointed in the right direction.

Recently, the full text of the HITECH Act was added to HSG online so that you can point and click to a relevant section of the statute and thereby read the primary authority as it is written, as opposed to relying on someone else's interpretation.

The next release of the HSG online version will also contain not only our paraphrased interpretation of the HIPAA Privacy and Security Rules, but the full text as well. In every place that a section of the Rules refers to another section (which happens often) you will be able to click on the referenced section.

In short, while the content available on the Internet is not a panacea, it is certainly a good idea to leverage what is out there.

Part VII of this series can be found here.

Check out a FREE EHR Checklist. If you would like more information regarding EHR implementations, and related compliance issues, sign up for our FREE HITECH/HIPAA Compliance Newsletter.