Reported PHI Breaches

The Department of Health and Human Services (“HHS”) maintains an online list of covered entities and business associates that have experienced PHI breaches where more than 500 individual patient records were involved.  As of the writing of this post, a total of 572 reported breaches are listed on this website.  What can we learn from this information?

First, the dataset covers breaches reported from September, 2009 through February, 2013.  A total of more than 21 million patient records are listed on this report (though it is likely there is some duplication of patient records between data breaches reported here).  These incidents total less than the single data loss reported by the Department of Veterans Affairs in 2006 when a single laptop was stolen from an employee’s home that contained in excess of 26 million records.  Nonetheless, a significant amount of PHI has been lost or stolen and reported to HHS over the last three and a half years.

Second, the most common scenarios for PHI breaches are tape backups that are lost, followed by theft.  Almost 6 million patient records were affected by this kind of data loss.  The theft or loss of a laptop came in fourth, affecting about 2.3 million patient records.  Theft generally accounted for more than one third of all records compromised, followed next by loss (which probably includes scenarios like we accidentally put the backup tapes in the dumpster, or the tape fell out of my bag between the office and my car), also accounting for about one third of all records compromised.  Hacking appears down the list, affecting a total of 1.3 million patient records.

Third, a little more than half of data breaches appear to involve a business associate of a covered entity in terms of patient records breached.  However, only 92 of the 572 data breaches note a business associate’s involvement, which tends to suggest that when a business associate is involved, more records on average are affected by the data breach.  This is consistent with the expectation that technology vendors like those that implement and/or host electronic health records often do so for more clients and are a bigger target for data theft or hacking and computer viruses.

With the change in breach notification in the final HIPAA regulations recently issued by HHS, it will be interesting to see if there are more breach notifications published to HHS’ web site.

Changes in HIPAA Breach Notification Rule

HHS recently released the final regulations that revise certain provisions of HIPAA, including the HIPAA breach notification rule.  Congress, in enacting the HiTech Act in 2009, included a statutory requirement that covered entities report breaches that involved the unauthorized access or loss of protected health information (“PHI”).  HHS then promulgated an interim rule to implement this statutory provision.  That interim rule required reporting of the breach under the “significant risk of financial, reputational or other harm” standard.  Criticism was subsequently leveled at this standard as being too subjective.  HHS just recently issued its final rule (effective on March 26, 2013) that changes the breach reporting rule in two ways.

First, if there is a breach that involves PHI, and the breach does not fall within a regulatory exception, the presumption of the regulation is that the breach must be reported.  This means that a party that experiences a loss of PHI cannot assume, on the grounds that the loss was uncertain to cause significant harm to the patients, that notification of the breach was not required.

Second, the final regulation replaces the interim rule’s standard with a requirement that the party who experienced the loss must demonstrate that there is a low probability that the PHI has been compromised.  In order to qualify under this new standard, the party must perform a risk assessment, taking into account at least the four factors outlined in the regulation.  These factors are found in § 164.402(2):

(i) The nature and extent of the protected health information involved, including the types of identifiers and the likelihood of re-identification;

(ii) The unauthorized person who used the protected health information or to whom the disclosure was made;

(iii) Whether the protected health information was actually acquired or viewed; and

(iv) The extent to which the risk to the protected health information has been mitigated.

So, let’s evaluate some typical hypothetical scenarios that involve the loss of PHI.  The most common reported PHI breach involves data backup tapes that are lost.  By design, a data backup tape is usually the entire database of patient records, because this entire dataset would normally be required to restore the data from the backup.

Under the first factor, such a loss would militate towards breach notification, because the dataset would almost certainly include patient identifiers and, if the backup was of an electronic health record, extensive health information on each patient.  Under the second factor, if the tape was merely lost, there is no determination of who might have had unauthorized access to the PHI.  If, for example, the backup tape was just simply lost by a contractor that stores the backup tapes in a vault for retrieval on demand, this factor might lean towards not making a notification.  On the other hand, if the tape was in the trunk of the network administrator’s car, and the car was stolen, this factor might lean towards making a notification.

As to the third factor, a lost data tape alone, without more information, would not inform us whether the data was actually acquired by anyone, or viewed by someone.  There is certainly the potential that a lost tape could be viewed, assuming that the person that obtained it had access to a compatible tape drive.  But based on what we know, this factor is probably neutral.

As to the fourth factor, the question here is whether the backup tape itself was encrypted, or was stored in a locked storage box.  A tape that is encrypted is much harder to access, even if the tape was intentionally stolen to obtain unauthorized access to PHI.  A tape in a locked storage box that was merely lost may be less likely to be accessed by an unauthorized user.  So this factor may swing either way based on what, if any, mitigations were in place to protect the data on the backup tape.

If we assumed that no mitigations were in place, the overall analysis would lean towards breach notification under the new rule.  As you can see, however, the facts and circumstances matter greatly in evaluating whether a breach has occurred that requires notification.

Changes in HIPAA Compliance

The HiTech Act set in motion a series of changes to Health Insurance Portability and Accountability Act (“HIPAA”) compliance for covered entities and business associates in 2009, which were followed by interim regulations issued by the department of Health and Human Services (“HHS”).  HHS has issued a final regulation that goes into effect on March 26, 2013, and requires compliance within 180 days by all covered entities and business associates.

The HiTech Act made a number of important changes to the law governing the security and disclosure of protected health information.  First, prior to HiTech, business associates of covered entities were not required to comply with the security rules and standards set forth in the HIPAA security regulations.  HiTech changed the applicability of the security regulations to include business associates.  The final regulation from HHS implements this provision of the HiTech Act.

Second, prior to HiTech, there was no federal requirement that a covered entity or business associate report a security breach that resulted in the disclosure of protected health information (“PHI”).  HHS subsequently issued interim regulations to implement these notification requirements, and as of March 26, 2013, HHS issued final regulations that alter the assumptions and exceptions to what constitutes a “breach” under HIPAA.

Business Associates are Covered Entities when it comes to PHI

HiTech initially changed the law governing PHI by requiring that business associates comply with the same security regulations that govern covered entities.  The final regulations with HHS clarify which security rules also apply to business associates under section 164.104 and 164.106, including those applicable rules found in Parts 160 and 162.  However, HHS also expanded the definition of “business associate” to include subcontractors of business associates that handle PHI on behalf of the business associate for the covered entity.  The regulation does provide certain narrow exceptions to who is now covered in the definition of a “business associate,” including an exception for “conduits” of PHI that may, on a transitory basis, transmit PHI but would not access the PHI except on a random or infrequent basis.  But the regulation appears to generally expand further the legal responsibilities, and potential liability, for members of the industry that work even indirectly for covered entities.

For existing health care providers, now might be the time to revisit your business associate agreement with your business associates, such as your EHR vendors.  Section 164.314 establishes certain requirements for these agreements, including provisions that all business associates comply with the full security rule, that subcontractors to business associates also comply with the full security rule, and that business associates provide the covered entity with security incident reporting in the event of a breach at the business associate’s or subcontractor’s facility or systems.

Changes in Security Breach and Notification

HiTech also introduced a breach notification provision which was intended to require covered entities to report to HHS, and where appropriate, to patients affected by a security breach involving their PHI.  The final regulations have modified the definition of a “breach” by establishing the assumption that an unauthorized access of PHI is a breach unless it can be demonstrated by the covered entity or business associate that there is a low probability that the PHI has been compromised.

Such a demonstration requires that the covered entity or business associate conduct a risk assessment and evaluate at a minimum the four factors described in the regulation: “(i) the nature and extent of the protected health information involved, including the types of identifiers and the likelihood of re-identification, (ii) the unauthorized person who used the protected health information or to whom the disclosure was made, (iii) whether the protected health information was actually acquired or viewed, and (iv) the extent to which the risk to the protected health information has been mitigated.”

Altering the burden and requiring a covered entity or business associate to engage in this risk assessment is likely to increase the number of breach notifications required under the final regulation.

The final regulation includes a variety of other changes in requirements for covered entities and business associates not discussed in this article, such as sale and marketing of PHI, use of genetic information for insurance underwriting, notices to patients of privacy practices, and disclosure of PHI to friends and families of decedents.  Providers should promptly examine their privacy and security policies to ensure compliance with the final regulations.

New Online Maryland Business Filings

Maryland’s State Department of Assessments and Taxation (SDAT) now accepts certain business filings online through its web portal, available here.  This web portal permits registration of a new business, registration of trade names, and establishing Maryland business tax accounts.  Users can now complete these documents without having to go in person or use SDAT’s fax system.  You should note that the expedited filing fees are charged for using this web site.

Trademark Research and Trademark Clearance – A Primer

We previously discussed trademarks in general and how they are used by businesses to distinguish their brand of product or service.  In this post, we will discuss the trademark clearance process, and the trademark registration process with the US Patent and Trademark Office.

Trademark Clearance

Trademark clearance is the process of evaluating potential brand names against existing brand names or designs that are in use in commerce.  Trademark clearance is important for two main reasons.  First, it is of no use to a new brand to overlap with the brand name of another business that is already being used in commerce.  This will tend to lead to consumer confusion about who makes your product.  Second, if another business is already using a particular mark, you run the risk of nasty letters from that business’ attorney, and potentially a lawsuit for infringement and/or dilution of that mark.  If you have already committed substantial money to develop and market a particular brand name, then discover that your mark is already in use by another in the same market area, not only will you lose the money invested in your marketing, but you could be sued.

You should always talk with an attorney licensed in your state before making decisions about your brand or design mark.

Market Research

Generally, a person starting out in business should conduct some research on similar or competing businesses that are already established in the market place.  For example, if you wanted to start a new information technology company that virtualizes physical servers, you would want to find out if there are other businesses with that kind of technology.  VMWare and Microsoft are major players in this market.  You would then want to take a look at the brand names that these companies use to distinguish their software for virtualization.  For example, Microsoft uses a brand name, “Hyper-V” or “Hyper-V Server” for this product offering.  VMWare uses a number of individual brand names for its suite of products.  You will note, however, that each one of these names begins with a lower case “v.”  This business also uses “VMWare” itself as a brand name when you peruse their marketing materials.

From this preliminary research, you would likely rule out a product name that included “Hyper-V” or “VM” or “VMWare” in your name.  You will also note that a lot of the literature on virtualization uses the marketing concept of “cloud” or “cloud computing.”  It is possible that there are companies that develop virtualization software that include the word “cloud” or “cloud computing” in their brand name.  For example, a google search for “cloud computing” turns up a paid ad for Oracle, HP, and a link to IBM’s web site.  So, “cloud” may also not make sense to be a part of your software’s brand name or identity.  You might also rule out starting out your product branding with the lower case letter “v,” as VMWare may enjoy “family of marks” protection.

Knowing what’s in use in the market can help you start thinking about how to describe your product, and how you want to distinguish your software from the existing companies that make this kind of software.  Understanding the words that are commonly used by customers or businesses that offer similar services to your new business will help you to get into the mindset for branding your company’s product or service.

Potential Brand Names

From here, you would want to work on developing a list of potential brand names for your product.  As you may be aware, the law recognizes varying degrees of protection for marks on a sliding scale.  Brands or marks that are merely descriptive of a product or service generally cannot be registered, except under specific circumstances (that the brand has been used in commerce for long enough to develop a secondary meaning).  Also, marks that are generic, which is, that tend to represent a category of goods (think “Thermos” which about 100 years ago was a trademark that became so effective that everyone called their hot drink carrier a thermos) cannot be registered.  These two groupings of marks will generally condemn the mark to little or no protection should another start using that mark with his or her goods.  (For a general discussion of trademark protection, take a look at the case of Abercrombie & Fitch v. Hunting World, Inc., 537 F.2d 4 (1976)).

However, a mark that is “suggestive” or is “arbitrary and fanciful,” which is a fancy way of saying that the mark is distinctive, will receive more protection from infringers.  For example, “Coke” or “Coca-Cola” are trademarks for a very well known brand of soft drink.  The word “coke” literally means a fuel that is derived from coal.  I doubt that one would say that this word would, in a literal way, have much of anything to do with a carbonated soft drink, but you could see why this might be suggestive – the caffeine in this soft drink powers many a late night programmer (along with pizza) to hack out some code for a morning deadline!

Clearance

Coming up with a list of potential names is a challenge for many businesses.  However, after you get the creative juices flowing and have a list, the next step is to work with a Trademark attorney to review your list to help narrow the field.  An attorney can help you to identify “generic” or merely descriptive proposed marks that are unlikely to be accepted for registration.  In addition, an attorney can perform a preliminary search to see if there are existing marks already registered that are the same or very similar to a proposed mark.  These steps will reduce your list of potential marks.

After this hurdle, you can identify what potential marks you want to pursue.  If appropriate, an attorney can order a more comprehensive search from a trademark search business to identify, more broadly, those marks already in use in commerce that may overlap with the proposed mark.  The attorney can then help you understand your chances at a successful registration of a proposed mark.

 

Note: Marks mentioned in this article are the property of their respective owners.  Use of these marks is not meant to imply endorsement of this article.

Implementing Stages of Meaningful Use

With the release of the final Stage 2 Meaningful Use regulations, CMS issued a CMS Press Release on Stage 2 that, among other things, attempted to clarify when practices that implement an EHR will need to comply with which stage of the regulations.  In the beginning of the incentive program, there was some concern that practices that delayed EHR adoption might have to jump right to a later stage of meaningful use to obtain any incentive money.  The following chart describes the current phased-in approach based on when a practice first adopts an EHR as compared to when that practice has to demonstrate which stage of meaningful use.

As you can see, for practices that decide to adopt an EHR in 2013, the individual eligible providers will be able to demonstrate compliance with the Stage 1 criteria in both 2013 and 2014, delaying the Stage 2 criteria to 2015.  Readers should note that Medicare eligible providers that delay implementing an EHR until 2015 will not be eligible for any incentive dollars; instead they will just be staving off the proposed Medicare reimbursement cuts of 1% per year (up to 5%) by adopting EHR.  See § 495.211.  For those Medicaid eligible providers, the last year one might adopt an EHR is 2017 to be able to receive any incentive payments (though such a provider would not have to meet the Stage 2 criterion until 2019).  See § 495.310.

Comparing Meaningful Use Stage 1 and Stage 2 Criteria

In an earlier post, I had analyzed side by side the final Stage 1 criteria for achieving meaningful use to the interim Stage 2 criteria that will be phased in starting in 2014.  Following that analysis, HHS released the final Stage 2 criteria.  As a result, the comparison has changed a bit from my post earlier this year.  The following two tables analyze the final Stage 1 Core and Menu Criteria in comparison to the same for the final Stage 2 criteria.

A few highlights on what changed between the interim and final Stage 2 criteria.  First, a few of the final Stage 2 criteria ended up reducing the compliance metrics from what was proposed in the initial Stage 2 criteria.  See 495.6(j)(1), (j)(9) and (j)(11).

However, a few of the Stage 2 criteria metrics were changed to include additional requirements for compliance which might present a curve ball for those of you planning on obtaining compliance with these.  For example, in the final Stage 2 regulation, the criterion on patient access to health information has an added metric that 5% of patients actually download information available electronically from the provider.  You may want to contact your information systems vendor to determine if the portal you are implementing can provide you with this kind of information as it may not be collected and stored in a way that a report could be generated to evaluate compliance.

In addition, a new Menu criterion was added in the final Stage 2 regulations, found at 495.6(k)(6).  Here, a practice could elect to enter patient chart information as structured data; the metric requires that 30% of patients that are seen during the reporting period have data entered in this manner.  As a practical matter, many EHR systems today will store documented patient information as structured data where the patient visit is documented electronically as a part of the patient visit.  This might be an easy Menu criterion to comply with (as you need to pick three of the six total criteria in the final Stage 2 regulations).

Table 1 – Core Criteria Under Stage 1 and Stage 2 Meaningful Use Comparison

Eligible Providers must meet all of the Core Criteria to Qualify for the Incentives.  Stage 1 had 15; Stage 2 has 17.  Stage 1 meaningful use Core Criteria are found in section 495.6(d) for eligible providers.  Stage 2 meaningful use Core Criteria are found in section 495.6(j) for eligible providers.

Core Criteria for EPSubsections (d), (j) Stage 1 Metric Stage 2 Metric
§ 495.6(j)(1) – provider use of CPOE for medication, lab, and radiology orders [§ 495.6(d)(1)] 30% of orders 60% of medication orders;30% of lab and rad orders
§ 495.6(d)(2) – drug-drug and drug-allergy checking Enabled during period moved to 495.6(j)(9), same metric
§ 495.6(d)(3) – maintain up to date problem list 80% of patients subsumed into transition of care requirement.
§ 495.6(j)(2) electronic prescriptions [§ 495.6(d)(4)] 40% of Rx 50% of Rx
§ 495.6(d)(5) – active medication list 80% of patients subsumed into transition of care requirement.
§ 495.6(d)(6) – active allergy list 80% of patients subsumed into transition of care requirement.
§ 495.6 (j)(3) demographics [§ 495.6(d)(7)]50% of patients with encounters 80% of patients with encounters
§ 495.6 (j)(4) vital signs [§ 495.6(d)(8)]50% of patients with encounters 80% of patients with encounters
§ 495.6 (j)(5) smoking status [§ 495.6(d)(9)]50% of patients with encounters 80% of patients with encounters
§ 495.6(d)(10) – reporting clinical measures to CMS or State Successful testing not a separate criterion; CQM submission required
§ 495.6 (j)(6) decision support [§ 495.6(d)(11)] Implement 1 decision support intervention Implement 5 decision support interventions
§ 495.6 (j)(7) lab results as structured data [§ 495.6(e)(2)] Was Menu in Stage 1; 40% of all lab results 55% of all lab results
§ 495.6 (j)(8) patient lists by specific condition for QI [§ 495.6(e)(3)] Was Menu in Stage 1; at least 1 list At least 1 list
§ 495.6 (j)(9) patient reminders [§ 495.6(e)(4)] Was Menu in Stage 1; 20% of patients sent during period 10% of patients seen in last 2 years receive a reminder
§ 495.6 (j)(10) patient electronic access of health information [§ 495.6(e)(5)] Was Menu in Stage 1; 10% of patients receive timely access 50% of patients receive timely access & 5% actually download information
§ 495.6 (j)(11) clinical summaries at patient visit [§ 495.6(d)(13)] 50% receive summary from office visit 50% receive summary from office visit
§ 495.6 (j)(12) patient education resources [§ 495.6(e)(6)] Was Menu in Stage 1; 10% of patients receive ed. resources 10% of all office visits
§ 495.6 (j)(13) medication reconciliation for transition of care [§ 495.6(e)(7)] Was Menu in Stage 1; 50% of transitions have recon 50% of transitions of care have medication recon
§ 495.6 (j)(14) patients transitioned to another provider’s care have care summary prepared by provider [§ 495.6(e)(8)] Was Menu in Stage 1; 50% of transitions have recon 50% of transitions of care have patient summary; 10% of transitions must involve exchange of data
§ 495.6 (j)(15) capability to submit electronic data to immunization registry [§ 495.6(e)(9)] Was Menu in Stage 1; perform 1 test to registry Ongoing submission of data to registry during CY
§ 495.6 (j)(16) security risk assessments under HIPAA security regulations [§ 495.6(d)(15)] Conduct security assessment Conduct security assessment
§ 495.6 (j)(17) use electronic messaging to communicate with patients N/A 5% of patients seen during period received secure message from provider
[§ 495.6(d)(14)] – capability to exchange key clinical information among care providers and patients One test of exchange N/A
[§ 495.6(d)(12)] 50% of patients receive timely access 50% in 3 days on patient request N/A

Table 2 – Menu Criteria Under Stage 1 and Stage 2 Meaningful Use Comparison

In Stage 1, EP had to meet 5 out of 10 Menu Criteria to qualify.  In Stage 2, EP must meet 3 out of the 6 Menu Criteria to qualify.  Stage 1 meaningful use Menu Criteria are found in section 495.6(e) for eligible providers.  Stage 2 meaningful use Menu Criteria are found in section 495.6(k) for eligible providers.

Menu Criteria for EPSubjections (e), (k) Stage 1 Metric Stage 2 Metric
§ 495.6(k) (1) – access to imaging results in EHR N/A 10% of imaging results in EHR
§ 495.6(k) (2) patient family health history in structured data N/A 20% of all patients seen
§ 495.6(k) (3) capability to submit syndromic surveillance data to public health agency [§ 495.6(e)(10)] Was Menu in Stage 1; perform 1 test to registry Successful ongoing submission of data for period
§ 495.6(k) (4) capability to identify and report cancer cases to State cancer registry N/A Successful ongoing submission of data for period
§ 495.6(k) (5) capability to report other specialized registry (other than cancer) to specialized registry N/A Successful ongoing submission of data for period
§ 495.6(k) (6) record electronic notes in patient records N/A 30% of patients seen during the reporting period
[§ 495.6(e)(1)] – implement drug formulary checking Enable functionality Moved to Core / decision support
[§ 495.6(e)(2)] – lab results as structured data 40% of lab results are structured data Moved to Core
[§ 495.6(e)(3)] – generate lists by specific conditions 1 reporting list Moved to Core
[§ 495.6(e)(4)] – send reminders to patients for follow-up care 20% of patients Moved to Core
[§ 495.6(e)(5)] – Provide patients with timely access to health information 10% of patients have electronic access Moved to Core
[§ 495.6(e)(6)] – Use EHR for patient education 10% of patients Moved to Core
[§ 495.6(e)(7)] – Incoming transition of care to EP medication reconciliation 50% of patients have medication recon Moved to Core
[§ 495.6(e)(8)] – Outgoing transition of care from EP care record summary 50% of patients have care summary Moved to Core
[§ 495.6(e)(9)] – immunization registry 1 certified test Moved to Core