NIST

Subscribe to NIST

I’m sure fellow bloggers Bill Maruca and Michael Kline join me in giving three cheers for the recent growth in our firm’s health care practice (welcome, Minneapolis!) and ever-deepening pool of attorneys dealing with clients’ privacy and data security issues. But one recent addition to our team, Margaret (“Margie”) Davino, gets a fourth cheer for jumping into her new position as a partner practicing out of our New York City and Princeton, NJ offices and immediately leading a HIPAA webinar for HFMA’s Region 2 (metro NY) entitled “HIPAA: What to Expect in 2016”.

Margie covered a wide range of HIPAA topics, discussing how OCR investigations arise, preparing for Phase 2 of OCR’s audits, and how HIPAA might overlap or interplay with other laws (the FTC Act, state law causes of action, and the Telephone Consumer Protection Act, to name a few). For HIPAA nerds like me, it was a satisfying smorgasbord of HIPAA tidbits, past, present and future.  But several of Margie’s take-aways are particularly useful additions to the 2016 HIPAA compliance “To-Do” list:

  1. Make sure your security risk analysis encompasses all entities within your “family” – in other words, don’t just analyze your electronic health record, but focus on each entity and location from which protected health information (PHI) might be stolen or lost.
  2. If you are a small entity, make use of HHS’s Security Risk Assessment Tool to identify whether corrective action should be taken in a particular area. (In other words, there’s no excuse for ignoring item #1 on this list!)
  3. Encrypt data, if at all possible (and make sure it’s up to NIST encryption standards).
  4. Check that you have updated Business Associate (BA) Agreements in place for all BA relationships (and check first to make sure it’s really a BA relationship).
  5. Have a mobile device policy – and include mobile devices in your security risk analysis.

I like this short “To-Do” list because it helps prioritize HIPAA compliance tasks for 2016 based on what we have learned from breaches and enforcement actions in 2015 and prior years.

Health care vendors beware: if you tell customers that your product provides industry-standard encryption of protected health information in compliance with HIPAA, you’d better be sure it doesn’t simply “camouflage” the data.

The FTC recently announced a $250,000 settlement with Henry Schein Practice Solutions, Inc. (“Henry Schein”) for falsely advertising that the software it marketed to dental practices provided “industry-standard encryption of sensitive patient information” and “would protect patient data” as required by HIPAA.

In fact, according to the FTC’s Complaint, the software (called “Dentrix G5”) actually used a data protection tool Henry Schein knew was “less secure and more vulnerable than widely-used, industry-standard encryption algorithms, such as Advanced Encryption Standard (“AES”) encryption.” The Complaint states that Henry Schein was aware that the Department of Health and Human Services (“HHS”) directs health care providers to guidance promulgated by the National Institute of Standards and Technology (“NIST”), which recommends AES encryption to protect patient data.

The Complaint states that Henry Schein’s product did not use AES encryption, and alleges that Henry Schein was notified that its database engine vendor had agreed to re-brand the data protection used by Henry Schein as “Data Camouflage” so it would not be confused with standard encryption algorithms, like AES encryption. Still, Henry Schein allegedly continued to market its product as offering data encryption needed for HIPAA compliance.

In January of 2014, the Complaint concedes, Henry Schein published an announcement in the Spring 2014 issue of Dentrix Magazine stating:

“Available only in Dentrix G5, we previously referred to this data protection as encryption. Based on further review, we believe that referring to it as a data masking technique using cryptographic technology would be more appropriate.”

Alas, the admission that the product provided mere “data masking” or “camouflaging” rather than encryption was, apparently, too little and too late to avoid the FTC enforcement action and ensuing settlement payment and negative publicity. Though no data breach was alleged to have occurred, the damage had been done by the “false or misleading” claims already made by Henry Schein.

The lessons for covered entities and business associates using and marketing patient data tools? Simple:

(1) Encrypt, don’t camouflage (check NIST guidance and recommendations for current encryption standards).

(2) Don’t exaggerate your capabilities (don’t say you encrypt, when you merely camouflage, and if you only use some process like password protection, don’t suggest that you encrypt or even camouflage – potential misleading in this area can bring FTC sanctions).

(3) As we’ve said before on this blog, don’t forget that the FTC is watching – health care providers, payers, and vendors must remember that HHS isn’t the only sheriff in town when it comes to data protection, HIPAA isn’t the only law that governs patient data and privacy, and the States are also increasingly active in enforcing data privacy and security.

When and how should you email PHI, if at all?  The Office for Civil Rights (OCR) offers guidance as to the permissibility of sending PHI via email in this “Frequently Asked Question” answer, but doesn’t provide specifics as to how PHI can be safely emailed.  Whether you are a covered entity or a business associate (or the CIO or Privacy Officer for a covered entity or business associate), an attorney trying to navigate privacy and security compliance under HIPAA and other laws, or an individual whose PHI is at stake, you may wonder what tools and resources are available to protect PHI transmitted via email.

The National Institute of Standards and Technology (NIST) has provided many such tools and resources, including its 2007 “Guidelines on Electronic Mail Security”.  Now, though, NIST is accepting comments through November 30, 2015 on its most recent proposed set of email security guidelines, “Special Publication 800-177, Trustworthy Email”.  Though this Trustworthy Email draft (available with other NIST computer security and privacy publications here) comes with a disclaimer that it is “written for the enterprise email administrator, information security specialists and network managers”, it’s worth review (even by the less tech-savvy among us) because it breaks down and describes each component of email functionality and the protocols and technology currently available to improve privacy and security.

Emailing PHI has become extremely common, but before deciding to send or receive PHI via email, it’s a good idea to make sure the Trustworthy Email protocols and technologies have been considered.   And if you have suggestions or comments as to how these protocols and technologies specifically relate to or can be improved in the context of emails containing PHI, here’s your chance to speak up!  Finally, remember that whatever comes out as the final set of NIST guidelines can become obsolete quickly in this rapidly developing and expanding e-world.

Congratulations!  You have a HIPAA-compliant business associate (or subcontractor) agreement in place – now what? How can you implement the agreement without becoming a HIPAA guru?

There are many resources available that offer detailed guidance on risk analysis and implementation protocols (such as the Guide to Privacy and Security of Electronic Health Information published by the Office of the National Coordinator for Health Information Technology and numerous “Special Publications” issued by the National Institute of Standards and Technology (NIST)).

These are terrific resources and can keep a team of IT professionals and Privacy and Security Officers reading and scratching their heads for weeks, but here are a few simple and practical steps you can take to avoid the security incident that may result in a protected health information (PHI) breach.

  1. Make sure the covered entity knows which individual(s) is authorized to receive PHI at the business associate. If neither the services agreement nor the business associate agreement specifies the person to whom PHI is to be disclosed, make sure the name, title and contact information of any designated recipient is communicated to the covered entity in writing.
  2. Include a provision in the business associate agreement (or subcontractor agreement) or develop a process whereby the covered entity (or business associate) provides notice, when feasible, prior to transmitting PHI to the designated recipient. Particularly when the transmission of PHI is sporadic or infrequent, provision of advance notice helps heighten awareness of the parties’ HIPAA obligations with respect to particular data being transmitted.
  3. Establish an agreed-upon means of PHI transmission – for example, specify whether transmission will be made via encrypted email, portable device, hard copy, etc. – and document the chain of custody from covered entity to business associate and after receipt by business associate.
  4. Create a “vault” for PHI received by the business associate that is secured by access codes that are changed periodically and can be deactivated when personnel leave the employ of the business associate.
  5. Maintain a perpetual inventory of PHI repositories, delegating responsibility to the Security Officer to oversee or authorize repository access rights, review activity, and conduct regular audits.

As our partner Mark McCreary writes in his post describing the “Framework for Improving Critical Infrastructure Cybersecurity” published by the National Institute of Standards and Technology (NIST):

The Framework is designed to work with businesses to reach a sufficient level of cybersecurity protection regardless of size, sector, or level of security.  The Framework consists of three parts (1) The Framework Core, (2) The Framework Implementation Tiers, and (3) The Framework Profiles.  The Framework Core is a grouping of cybersecurity activities based on industry indicators, desired outcomes, and practices.  It assists businesses in developing Framework Profiles, which are used to create cybersecurity plans.

So how can a health care covered entity (such as a health care provider or health plan) or business associate use the Framework to help with HIPAA compliance?

1.  Review health industry-specific guidance available on NIST’s Framework website, such as that issued by the Health Information Trust Alliance (HITRUST).

2.  Review the Framework and Framework’s FAQs to build a Framework Core that applies in the context of your business activities — for example, include Framework outcome language such as “physical devices and systems within the organization are inventoried” and a Framework category for “Electronic Health Record Access Control”.

3.  Realize that the Framework can be used to improve or strengthen your PHI security by layering it over or weaving it into your HIPAA Privacy and Security Policies and Procedures.

 

Our blog posts have been somewhat fewer and farther between since the release of the Omnibus Rule, primarily because we have been busily working to understand the subtleties of the Omnibus Rule, while helping our clients implement the necessary changes. We have also seen a sharp uptick in inquiries related to breaches and potential breaches. But sometimes it’s worth focusing on the more mundane aspects of HIPAA compliance in this new post-Omnibus, high-tech, HIPAA-happy (or HIPAA-headache-inducing, depending on one’s perspective) world. 

One such mundane, but important, issue has plagued some of our most diligent, compliance-seeking business associate and covered entity clients. They ask: Where do we draw the line between a run-of-the-mill, ordinary garden variety “security incident” and a “presumed breach” when it comes to reporting? How do we describe these types of reporting obligations in our Business Associate Agreements? 

The Omnibus Rule doesn’t help much to answer this question. The definition of “breach” has been revised under the Omnibus Rule, but the definition of “security incident” remains broad. A “security incident” includes “the attempted or successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations in an information system.” The Omnibus Rule also requires business associate agreements to require business associates to “[r]eport to the covered entity any security incident of which it becomes aware, including breaches of unsecured protected health information as required” by the breach notification requirements of the Omnibus Rule. Really? Does HHS truly expect us to give or get reports of every attempted hacking incident? What about system interferences caused by power outages?  What if a paper medical record is left on a table or chair unattended for several minutes (or hours), whether in a public or even a private area? The potential examples of gray areas are limitless.

I think the quick answer is that not all reports are created equally. Yes, the Omnibus Rule makes it clear that almost every unauthorized “acquisition, access, use, or disclosure” is presumed to be a breach (unless a “low probability” the information has been compromised is demonstrated in accordance with a risk assessment that includes at least four minimum factors), and triggers very specific reporting obligations. Reports must be given within specific periods of time, and must include specific information. However, the Omnibus Rule does not require this type of specificity for reports of “security incidents” that do not rise to the level of being breaches or presumed breaches. 

The National Institute of Standards and Technology (NIST) issued a “Computer Security Incident Handling Guide” in August of 2012, approximately 6 months before the Omnibus Rule was released. One guideline seems particularly relevant when it comes to figuring out how to deal with various types of “security incidents”:

                        Organizations should create written guidelines for prioritizing incidents.

 

Prioritizing the handling of individual incidents is a critical decision point in the incident response process. Effective information sharing can help an organization identify situations that are of greater severity and demand immediate attention.  Incidents should be prioritized based on the relevant factors, such as the functional impact of the incident (e.g., current and likely future negative impact to business functions), the information impact of the incident (e.g., effect on the confidentiality, integrity, and availability of the organization’s information), and the recoverability from the incident (e.g., the time and types of resources that must be spent on recovering from the incident).

Let’s pay attention to NIST and prioritize our security incident reporting based on relevant factors. Of course, we want to ensure HIPAA compliance and appropriate breach and potential breach prevention, reporting, and mitigation, but let’s not clog operational waterways with “incident” reporting overload. 

The OIG is conducting a survey of hospitals who have certified the meaningful use of Electronic Health Record (EHR) Technology, with an emphasis on safeguards that protect the EHR systems from fraudulent access or alteration. A generous hospital compliance officer who has asked to remain nameless has provided me with a copy of the survey tool which can be accessed here.

Topics addressed in the survey include:

 

  • Coding capabilities
  • User authentication and access
  • Access to EHR by outside entities
  • Audit log and metadata features
  • Methods for entering physician and nursing notes
  • Capabilities for exporting and transmitting EHR documents
  • Patient access
  • Patient identity management
  • Additional features and safeguards.

The underlying thread of the questionnaire looks to determine what each hospital is doing to ensure the integrity of the EHR data gathered, and to identify the barriers to more effective implementation of electronic records.

 

Meanwhile, back on Capitol Hill, a hearing was held on November 14, 2012 before the House Subcommittee on Technology and Innovation Committee on Science and Technology. The hearing topic was titled: Is ‘Meaningful Use’ Delivering Meaningful Results? An Examination of Health Information Technology Standards and Interoperability. Witnesses were asked to address in their testimony:

 

What is the goal for health information interoperability under the HITECH Act?

 

How are Stage 1 and 2 meaningful use requirements and supporting standards advancing us towards this goal?

 

How have the lessons learned from the implementation of Stage 1 meaningful use requirements and supporting standards been applied in drafting Stage 2 requirements and Stage 3 proposals?

 

How does the ONC engage Federal agencies and other stakeholders (National Institute of Standards and Technology (NIST), vendors, and providers) in developing the meaningful use requirements and technical standards?

 

How does the HIT Standards Committee balance the need for common IT standards with the diversity of the healthcare industry? How does the Committee account for technology development and innovation in its standards recommendations?

 

How effective have HHS and the ONC been in establishing long-term goals and benchmarks for HIT adoption, interoperability, and provision of care?

 

What recommendations would you make for Federal policy makers as we consider futureHIT policies?

 

Dr. Farzad Mostashari, HHS National Coordinator for Health Information Technology, presented prepared remarks which can be found here. Dr. Mostashari was cautiously optimistic about the pace of adoption of EHR and the progress being made toward interoperability.  He noted that as of September 2012, more than 300,000, more than half of the nation’s eligible professionals, as well as over 75 percent of eligible hospitals have registered to participate in the Medicare or Medicaid Incentive Programs.

 

Summarizing the lessons learned by HHS to date, Dr. Mostashari stated “By creating standards-based methods for the electronic submission, receipt and processing of health IT, Federal agencies can improve the quality of the data they receive while also reducing the number of expensive, one-off solutions for addressing the varied needs of the stakeholders they serve.” He praised his agency’s collaborations with NIST and recognized the over 6,400 comments received from stakeholders regarding the meaningful use process. He emphasized the efforts to provide new flexibility in definitions, exclusions, a shorter reporting period for the first year of Stage 2, and additional quality measures that account for the needs of many medical specialties to measure and improve the care they provide. He also called attention to the Standards and Interoperability Framework, a Wikipedia-style site for EHR developers, which he described as an example of “government as a platform” – enabled by integrated functions, processes, and tools – for the open community of implementers and experts to work together to develop and harmonize health information exchange standards.

 

Other witnesses appearing before the committee included Dr. Charles H. Romine, Director, Information Technology Laboratory, National Institute of Standards and Technology; Marc Probst, Chief Information Officer and Vice President, Information Systems, Intermountain Healthcare; Ms. Rebecca Little, Senior Vice President, Medicity; and Dr. Willa Fields, DNSc, RN, FHIMSS, Professor, School of Nursing, San Diego State University.

 

In his introductory remarks, subcommittee chairman Ben Quayle (R-AZ) noted :

 

Given our current budget situation, it is vital that these taxpayer dollars are spent effectively in ways that lead to reduced costs and better health care down the road. Nearly four years after the HITECH Act, taxpayers should know what we have to show for it.

 

The recent survey suggests that the OIG intends to supply Rep. Quayle’s subcommittee with a detailed answer to that question.

As HITECH refocuses the health care industry’s attention on security, the role of National Institute of Standards and Technology (“NIST”) in developing standards for health information security will become more center stage.  

On May 18, 2009, Fox Rothschild LLP will present at the NIST and CMS Security Rule Conference in Gaithersburg, Maryland called: “Safeguarding Health Information:  Building Assurance Through HIPAA Security”.   Elizabeth Litten, Esq., a partner of Fox Rothschild’s Health Law Group, and Co-chair of its Government Relations practice group, will be presenting at the NIST/CMS Security Conference as part of a Panel Discussion on Assessments from the Organizational Perspective.   The panel will share its experiences with, and expectations for, audits, assessments, and compliance reviews, and provide strategies for greater assessment efficiencies.   For further information on the NIST/CMS Security Rule Conference, please visit the NIST website. 

 

For a copy of the Power Point presentation prepared by Elizabeth and Helen Oscislawski, Esq. for the NIST/CMS Security Rule Conference please visit our Blog again next week, or if you subscribe to our Blog a copy will be e-mailed to you directly.