In some respects, HIPAA has had a design problem from its inception. HIPAA is well known today as the federal law that requires protection of individually identifiable health information (and, though lesser-known, individual access to health information), but privacy and security were practically after-thoughts when HIPAA was enacted back in 1996. HIPAA (the Health Information Portability and Accountability Act) was originally described as an act:

To amend the Internal Revenue Code of 1986 to improve portability and continuity of health insurance coverage in the group and individual markets, to combat waste, fraud, and abuse in health insurance and health care delivery, to promote the use of medical savings accounts, to improve access to long-term care services and coverage, to simplify the administration of health insurance, and for other purposes.”

The privacy of individually identifiable health information was one of those “other purposes” only peripherally included in the 1996 act. Privacy protection was to be a follow-up, a “to-do” checklist item for the future. HIPAA directed the Secretary of Health and Human Services to recommend privacy standards to specified congressional committees within a year of enactment, and, if Congress did not enact privacy legislation within 3 years of enactment, the Secretary was to proceed with the promulgation of privacy regulations. Security was a bit more urgent, at least in the context of electronic health transactions such as claims, enrollment, eligibility, payment, and coordination of benefits. HIPAA required the Secretary to adopt standards for the security of electronic health information systems within 18 months of enactment.

This historical context casts some light on why our 2017-era electronic health records (EHR) systems often lack interoperability and yet are vulnerable to security breaches. HIPAA may be partially to blame, since it was primarily designed to make health insurance more portable and to encourage health insurers and providers to conduct transactions electronically. Privacy and security were the “oh, yeah, that too” add-ons to be fully addressed once electronic health information transactions were underway and EHR systems needed to support them already up and running. Since 1996, EHRs have developed at a clunky provider-by-provider (or health system-by-health system) and patient encounter-by-patient encounter basis, not only making them less accurate and efficient, but vulnerable to privacy and security lapses. (Think of the vast quantity of patient information breached when a hospital’s EHR or a health plan’s claims data base is hacked.)

This past June, I participated on a California Israel Medical Technology Summit panel discussing privacy and security issues. An audience member asked the panel whether we thought blockchain technology was the answer to HIPAA and other privacy and security-related legal requirements. I didn’t have a good answer, thinking “isn’t that the technology used to build Bitcoin, the payment system used by data hackers everywhere?”

This past July, Ritesh Gandotra, a director of global outsourcing for Xerox, wrote that blockchain technology could overhaul our “crippled” EHR management system. Gandotra writes “Historically, EHRs were never really designed to manage multi-institutional and lifetime medical records; in fact, patients tend to leave media data scattered across various medical institutes … This transition of data often leads to the loss of patient data.” He goes on to explain how blockchain, the “distributed ledger” technology originally associated with Bitcoin, can be used to link discrete patient records (or data “blocks”) contained in disparate EHRs into “an append-only, immutable, timestamped chain of content.”

Using blockchain technology to reconfigure EHRs makes sense. Ironically, the design flaw inherent in HIPAA’s original 1996 design (the promotion of electronic health transactions to foster portability and accountability in the health insurance context while treating privacy and security as an afterthought) can be fixed using the very same technology that built the payment network favored by ransomware hackers.

“Maybe” is the take-away from recent guidance posted on OCR’s mHealth Developer Portal, making me wonder whether the typical health app user will know when her health information is or is not subject to HIPAA protection.

The guidance is clear and straightforward and contains no real surprises to those of us familiar with HIPAA, but it highlights the reality that HIPAA, originally enacted close to 20 years ago, often becomes murky in the context of today’s constantly developing technology. Here’s an excerpt from the guidance that illustrates this point:

Consumer downloads to her smart phone a mobile PHR app offered by her health plan that offers users in its network the ability to request, download and store health plan records. The app also contains the plan’s wellness tools for members, so they can track their progress in improving their health.  Health plan analyzes health information and data about app usage to understand the effectiveness of its health and wellness offerings.  App developer also offers a separate, direct-to-consumer version of the app that consumers can use to store, manage, and organize their health records, to improve their health habits and to send health information to providers.

Is the app developer a business associate under HIPAA, such that the app user’s information is subject to HIPAA protection?

Yes, with respect to the app offered by the health plan, and no, when offering the direct-to-consumer app. Developer is a business associate of the health plan, because it is creating, receiving, maintaining, or transmitting protected health information (PHI) on behalf of a covered entity.  Developer must comply with applicable HIPAA Rules requirements with respect to the PHI involved in its work on behalf of the health plan.  But its “direct-to-consumer” product is not provided on behalf of a covered entity or other business associate, and developer activities with respect to that product are not subject to the HIPAA Rules.  Therefore, as long as the developer keeps the health information attached to these two versions of the app separate, so that information from the direct-to-consumer version is not part of the product offering to the covered entity health plan, the developer does not need to apply HIPAA protections to the consumer information obtained through the “direct-to-consumer” app.

So if I download this app because my health plan offers it, my PHI should be HIPAA-protected, but what if I inadvertently download the “direct-to-consumer” version? Will it look different or warn me that my information is not protected by HIPAA?  Will the app developer have different security controls for the health plan-purchased app versus the direct-to-consumer app?

HIPAA only applies to (and protects) individually identifiable health information created, received, maintained or transmitted by a covered entity or business associate, so perhaps health app users should be given a “Notice of Non-(HIPAA) Privacy Practices” before inputting health information into an app that exists outside the realm of HIPAA protection.

My partner Elizabeth G. Litten and I were interviewed by Marla Durben Hirsch in the FierceEMR article “Healthcare Attorneys: New Business Relationships Will Create New EHR Problems.” It is always a pleasure for us to talk with Marla because she provokes our thinking in new areas.  While the full text can be found here as part of the December 19, 2013, issue of FierceEMR, a synopsis is noted below.

The healthcare industry already has experienced several unintended issues related to electronic health records, many of which involve privacy and security, patient safety and coding. But as implementation of EHRs begins to mature and providers step up organizational consolidation and integration in response to health reform, there will be additional unanticipated operational and business problems involving EHRs that will arise.

Confused about EHR certification? You’re not alone. In a post to the federal HealthIT Buzz blog entitled Perpetually Perplexed by Regulatory Interpretations? Separate the Fact from Fiction,  Steven Posnack , the Director of the Federal Policy Division of  the Office of the National Coordinator for Health Information Technology (ONC) has debunked five common misunderstandings related to EHR certification:

  • If an eligible professional or eligible hospital combines multiple certified electronic health record (EHR) Modules together (or a certified EHR Module[s] with a certified Complete EHR), that combination also needs to be separately certified in order for it to meet the definition of Certified EHR Technology – *FICTION*
  • The ONC-Authorized Testing and Certification Bodies (ONC-ATCBs) operate under contract with and receive funding from ONC – *FICTION*
  • The ONC-ATCBs favor big EHR technology developers – *FICTION*
  • As an EP or EH, you need to demonstrate meaningful use in the exact way that EHR technology was tested and certified – *FICTION* (mostly)  See the jointly posted ONC and CMS FAQs (#24 or 10473
  • Certifications “expire” every two years – *FICTION*

Posnack’s article confirmed two additional frequently-heard statements as factual:

  • Testing and certification under the Temporary Certification Program does not examine whether two randomly combined EHR Modules will be compatible or work together – *FACT*  
  • Certification doesn’t require that an EHR technology designed by one EHR developer make its data accessible or “portable” to another EHR technology designed by a different developer – *FACT*

A study conducted by MGMA indicates most doctors surveyed who have implemented electronic record systems are satisfied or very satisfied, and many report increased productivity and reduced costs as those systems are optimized, according to Modern Healthcare.  The full MGMA study may be downloaded here (registration required).  This report is highly recommended reading.

The study, funded by PNC Bank, tabulated over 4,500 responses from a variety of organizations representing over 120,000 physicians, over half of them in independent private practice. Of the respondents, 16.3 percent believed they had optimized their EHR.   One surprising finding – independent physicians are farther along in the process than hospital-employed physicians: 

Finding independent practices further along in EHR optimization than IDS- and hospital-owned practices might seem surprising at first glance. As components of larger systems with greater access to financial and technical resources and expertise, IDS- and hospital-owned practices would seem more likely to lead rather than trail independent practices in EHR adoption. Yet, aspects of hospital and IDS-ownership may slow EHR adoption; it also may slow integration of EHR with other technologies

The leading barrier to implementation of EHR cited was “Expected loss of productivity during transition to the EHR system”, followed closely by “Insufficient capital resources to invest in an EHR.” 

Most telling is Figure 12 in the report, which shows 85.8% of "optimized" EHR users satisfied or very satisfied with their systems overall; 56.5% of such users satisfied with the ability of the EHR to decrease practice costs; 61% of such users satisfied with the ability of the EHR to increase provider productivity; and 60.8% satisfied with the ability of EHR to increase practice revenue.  MGMA concludes:

These data indicate that EHR users find reaching full optimization of their system produces benefits, and that they are more likely to perceive these benefits than other users. Efforts to optimize an EHR implementation are likely to produce tangible benefits for a majority of EHR users.



 The American Hospital Association (AHA) weighed in with a 16-page comment letter requesting changes and delays in the standards for certification and implementation of electronic health records published by the Office of the National Coordinator for Health Information Technology on December 30, 2009. 

In the comment letter, AHA asked ONC to

  • clarify the allocation of responsibilities of providers and IT vendors;
  • provide a lead time of one year between finalization of the certification criteria and certification of vendor systems and an additional two years between the time when certified products are available in the market and when providers nationwide are expected to implement and begin using them;
  • streamline the certification process;
  • recognize that hospitals may customize and make modifications to EHR technology that was certified by a vendor without needing additional certifications; and
  • delay  the certification criteria and standard for the accounting of disclosures at least until the updated rule for accounting of disclosures is issued by the HHS Secretary.

They also asked ONC to expressly clarify that the encryption and hashing standards contained within the IFR do not impose any obligations upon HIPAA-covered entities beyond that which is already required by the HIPAA Security Rule, and asked that the audit alerting criterion be eliminated from the final rule.

The devil is in the definition, as least when it comes to getting financial incentive payments for the adoption of electronic health records (EHR). The American Hospital Association (AHA) recently asked the White House Office of Health Reform, the Department of Health and Human Services, and the Centers for Medicare & Medicaid Services to revise the definition of "hospital-based" so that physicians working in hospital outpatient clinics or hospital-based facilities can receive incentive payments from Medicare and Medicaid under the American Reinvestment and Recovery Act (ARRA).

In many ways, AHA’s request makes sense. If ARRA is to incentivize "meaningful use" of EHR, it should not exclude physician users practicing in off-site clinic or outpatient locations — these are often the very physicians whose implementation and use of EHR is key to the creation of a community-wide EHR infrastructure. In other ways, though, AHA’s request is a vexing reminder of the mental contortions required to maintain the old meanings and purposes of terms while introducing new ones.

Whether an outpatient or "provider-based" clinic qualifies as part of the hospital for reimbursement purposes varies from state to state and from payer to payer. AHA’s request to expand the definition for purposes of ARRA incentive payments seems to make sense from an EHR-policy implementation perspective, but folding in yet another "hospital-based" definition for ARRA purposes challenges the conceptual integrity of the word — and starts to make my head spin.

The AHA letter is available at

On November 2, 2009, the Texas-based Drummond Group Inc. announced in a Press Release that it will submit to become a certifying body upon the release of the Office of the National Coordinator for Health Information Technology (ONC) requirements for certifying bodies for Electronic Health Records (EHR).  ONC is currently working on the scope and definition of "meaningful use" for EHR, expected to be finalized in early 2010. Along with these new policies on meaningful use of EHRs, ONC announced plans to expand the number of EHR certification agencies to support the new initiative. 

Currently, the only approved EHR certification agency, since 2004, is the Certification Commission for Health Information Technology (CCHIT).

Google Health and National Hospice and Palliative Care Organization’s Caring Connections have partnered to allow patients to store and access their advance directives on line.  Advance directives are essentially "directions" that a person gives to their medical professionals about what interventions they wish to have provided or withheld under specific circumstances — especially in emergencies and at "end-of-life" moments — when such person can not express those wishes himself or herself.  Advance directives laws vary from state-to-state, but typically require such directives to be in writing, signed and to have a personal representative listed.

GoogleHealth and Caring Connections will offer a "living will" feature that allows users to download a free state-specific advance directive and store completed and signed scanned documents securely on line in their GoogleHealth account.  By "storing" such advanced directives in GoogleHealth’s centralized repository, the hope is to offer providers with a better method to insure that a patient’s true wishes with regard to health care interventions are honored.  But, will it?

What had me wondering is how exactly will the provider access the advanced directive on Google Health without the individual (who presumably has lost his or her ability to communicate) providing his or her password?   I suppose that in instances where a personal representative has been appointed, the individual could make sure to provide such password to his/her personal representative — but watch out, because if the personal representative changes, then the password may need to change too.  Another option may be for individuals to pre-authorize their entrusted health care provider with access to their personal Google Health account.  Yet, this also has problems where one does not necessarily know which emergency room provider might end up providing them with care. 

Nevertheless, even with its limitations, Google Health’s new advanced directive feature will likely be beneficial in many circumstances.  To learn more about GoogleHealth and Caring Connection’s new advance directive feature, click here.

[Installment 5 – Governance Considerations from HIT for the Board and Other Hospital Stakeholders] 

This is the fifth in a series of blog posts that relate to the governance concerns surrounding developments in HIPAA, HITECH and HIT. 

The other week, two separate and apparently unrelated events occurred on consecutive days with respect to electronic health records (“EHRs”) that dramatically underscore the focus of this series. Governing Boards of hospitals and other stakeholders must place a very high priority in their struggle to cope with the new and somewhat uneven landscape of health information technology (“HIT”).

On July 16, 2009, Health Data Management reported that “[t]he federal HIT Policy Committee has approved revised recommendations of a workgroup for an initial definition of ‘meaningful use’ of electronic health records systems. The report goes on to emphasize that “[t]he definition is important because providers must demonstrate meaningful use of EHRs to qualify for Medicare and Medicaid incentive payments starting in 2011 under the economic stimulus law.”

Therefore, health providers will have to meet minimum prescribed standards for their EHRs if they are to benefit in the future from the federal economic stimulus package under the HITECH Act to recoup a portion of the heavy costs that they will incur to implement their EHRs programs. 

On the following day, July 17, 2009, the federal Department of Veterans Affairs (“VA”) published a press release on its Web site that it will temporarily halt 45 information technology projects which are either behind schedule or over budget. These projects will be reviewed by the VA, and it will be determined whether these projects should be continued. The release goes on to say that each of the 45 affected projects will be temporarily halted with no further development until a new project plan that meets the requirements of Program Management Accountability System is created.

Some of the titles of the VA projects that will be halted include significant EHRs-related projects such as “Health Data Repository II,” “Clinical Data Service,” “Home Telehealth Development,” “Occupational Health Record Keeping System,” “Lab Data Sharing & Interoperability – Anatomic Pathology/Microbiology” and many others.

By simply securing additional funding from Congress, the VA, as an agency of the federal government that is generally a favorite of the legislators, can retool and retrench its EHRs initiatives after making a relatively embarrassing press release and perhaps enduring some criticism and lost time. 

The Boards of health care providers do not have the luxuries of the VA. They simply cannot afford false starts and mistakes if they are to meet the meaningful use standards of the HITECH Act on a timely basis. As this blog has stated in earlier installments, the survival of many hospitals is threatened by the uncertainties of possible health care reform, declining patient population, reduced reimbursement, heavy regulation, intense competition, dwindling donor contributions and heavy endowment losses for non-profit hospitals, a history of unclear returns from past substantial investments in HIT and many other factors. The costs of mistakes for the private sector hospitals are not simply the embarrassment or lost time of the VA. They are the huge outlays for conversion to EHRs and the potential for losing access to the federal stimulus funds.

These questions and others must be properly considered at a high level in the hospital, with committed Board oversight, in order to avoid or mitigate liability and loss that will result from expensive choices made with inadequate or incomplete information. 

 [To be continued in Installment 6]