HIPAA Compliance News » HIPAA Security

FTC Grants “Three-Month Delay of Enforcement of ‘Red Flags Rule’ Requiring Creditors and Financial Institutions to Adopt Identity Theft Prevention Programs”

Robert Hudock Esq CISSP — Fri, 01 May 2009 02:35:00 +0000

The FTC announced today that the enforcement date for the Red Flag Rules is being extended until August 1, 2009 (instead of May 1, 2009). The press release is at www.ftc.gov/bcp/edu/pubs/business/alerts/alt050.shtm, and a Web site with more resources to help covered entities design and implement identity theft prevention programs,

“>www.ftc.gov/redflagsrule.

HHS Releases Guidance on How to Render PHI “Unusable, Unreadable, or Indeciperable” That Relies on NIST to Define Acceptable Methods for Destruction and Encryption

Robert Hudock Esq CISSP — Sat, 25 Apr 2009 02:36:00 +0000

On April 17^th the Department of Health and Human Services ("HHS") released guidance (hitechrfi1 ) "specifying the technologies and methodologies that render protected health information unusable, unreadable, or indecipherable to unauthorized individuals for purposes of the breach notification requirements" (the "Guidance") pursuant to section 13402 of the American Recovery and Reinvestment Act of 2009. The guidance was effective upon issuance (April 17, 2009). Comments can be submitted on or before May 21, 2009 by posting on the HHS web site at http://www.hhs.gov/ocr/privacy.

Section 13402(h) defines "unsecured protected health information" as protected health information that is not secured through the use of a technology or methodology specified by the Secretary. Encryption and destruction are the only recognized methods. Details of implementing these two methodologies depend upon the situation and the process by which the data are encrypted and/or destroyed.

HHS Guidance refers the reader to an array of National Institute of Standards and Technology (NIST) special publications. HHS has raised the bar for covered entities, business associates, and vendors of personal health records. Unlike the HIPAA Privacy and Security regulations NIST publications provide very specific criteria that must be met. As a consequence we expect what HHS deems to be an appropriate level of due diligence will be something much different as we look to the future of HIPAA compliance.

We can be sure a thorough analysis by a covered entity as to the application of physical, technical and administrative safeguards will be essential. By my count covered entities and business associates must become familiar with at least ten of the core NIST special publications to gain a working understanding of the methods by which PHI can be rendered unreadable, destroyed, etc. The Guidance defines a framework on which appropriate safeguards for securing protected health information can be rationally evaluated. For example, the Guidance specifies vulnerabilities and where safeguards may need to be deployed to mitigate threats to protected health information. The following data "states" are enumerated within the Guidance:

Data in motion meaning data that is moving through a network, including wireless transmission;
Data at rest meaning data that resides in databases, file systems, and other structured storage methods;
Data in use meaning data in the process of being created, retrieved, updated, or deleted; and
Data disposed meaning discarded paper records or recycled electronic media).

While these categories are not new to computer security practitioners they represent a much more advanced approach as compared against earlier HIPAA privacy and security guidance. (Guidance at 12). The Guidance notes that HHS consulted the NIST when identifying appropriate safeguards. The reader is also directed to review the NIST Special Publication 800-66-Revision1 "An Introductory Resource Guide for Implementing the HIPAA Security Rule".

Encryption is one of the core methods to render PHI unreadable; however encryption encompasses domains such as cryptology, number theory, and crypto analysis for even the most well versed security expert understanding how to encrypt information properly is complex. HHS solves this problem simply by relying on NIST. PHI must be encrypted using a NIST approved algorithm and procedure to be considered unreadable. Electronic PHI is encrypted when "the use of an algorithmic process to transform data into a form in which there is a low probability of assigning meaning without use of a confidential process or key" (45 CFR 164.304) and key to decrypt the PHI has not been breached. Encryption identified by NIST and judged to meet this standard NIST's encryption standards is acceptable to render PHI unreadable. (Guidance at 16).

Current acceptable encryption methods include:

For data at rest the reader those methods contained within NIST Special Publication 800-111, Guide to Storage Encryption Technologies for End User Device; and
For data in motion those methods contained within the Federal Information Processing Standards (FIPS) 140-2 are acceptable. These methods are explained in detail in NIST Special Publications 800-52, Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations; 800-77, Guide to IPsec VPNs; or 800-113,Guide to SSL VPNs, and others which are FIPS 140-2 validated. (Guidance at 17).

In addition to encryption, destruction is also considered an acceptable method to render PHI unreadable and/or unusable. Acceptable methods for destroying PHI at this time:

Paper, film, or other hard copy media be shredded or destroyed such that the PHI cannot be read or otherwise reconstructed; and
Electronic media must be cleared, purged, or destroyed consistent with NIST Special Publication 800-88,Guidelines for Media Sanitization, such that the PHI cannot be retrieved. (Guidance at 17).

Proposed Health Breach Notification Rule Promulgated by the FTC Expands Potential Scenarios Where an Entity May Be Required to Report a Security Breach

Robert Hudock Esq CISSP — Tue, 21 Apr 2009 01:34:00 +0000

The Federal Trade Commission (FTC) released proposed regulations entitled the “Health Breach Notification Rule” (the Rule) on April 16. At this time we are concerned with the FTC’s broad interpretation of PHR related entities and PHR identifiable health information. Hopefully these terms will be more strictly defined in the Final Rule as the FTC addresses comments submitted by interested parties.

Generally the regulations implement new breach notification requirements for Personal Health Records (“PHRs”). The Rule was promulgated pursuant to section 13407(g)(1) of the American Recovery and Reinvestment Act of 2009 (the “Recovery Act”). The FTC Rule applies to vendors of personal health records and related entities not covered directly by HIPAA. The FTC’s Rule likely will parallel regulations that Department of Health and Human Services (“HHS”) will promulgate for entities covered by HIPAA no later than August 17.[1] Public comments on the FTC’s proposed Rule are due by June 1, 2009. Comments can be submitted online at https://secure.commentworks.com/ftc-healthbreachnotification/. The Final Rule will apply to security breaches on or after September 18, 2009. Table 1 (below) provides a summary of the new regulations for your reference. Details of particular note, including the broad application of the Rule, are discussed at length below.

Table 1 - Summary of PHR Breach Notification Rule

16 CFR 318, et sq.	Section & Description	Summary
	318.1 - Purpose and scope.	The Rule applies to vendors of Personal Health Records, PHR related entities, and third party service providers. The Rule does not apply to HIPAA-covered entities or to an entity’s activities as a business associate of a HIPAA-covered entity.
	318.2- Definitions.	Defines breach of security, personal health record, PHR identifiable health information, PHR related entity, third party service provider, unsecured, and vendor of personal health records.
	318.3 - Breach notification requirement.	Defines the scope of notice when under the Rule and when a breach is treated as discovered.
	318.4 - Timeliness of notification.	Notification must be made without unreasonable delay and in no case later than 60 days following Discovery. Defined burden of proof for delay beyond 60 days where requested by law enforcement.
	318.5 - Methods of notice.	First class mail generally, but other methods may be indicated in certain scenarios including media, posting on website, etc.
	318.6 - Content of notice to individuals	Notice should include a description of the incident, what information was compromised and guidance on how to protect against identity theft including resources available to the individual to assist mitigation of the security risk.
	318.7 – Enforcement	Non-compliance is treated as an unfair or deceptive act or practice in violation of a regulation under section 18(a)(1)( of the Federal Trade Commission Act (15 U.S.C. § 57a(a)(1)() regarding unfair or deceptive acts or practices.
	318.8 - Effective date.	September 18, 2009.
	318.9 – Sunset	Rule will sunset on the effective date of regulations implementing new legislation from Congress addressing PHR breach notification requirements.

Of particular note the Proposed Regulations expand the traditional scope of the FTC’s enforcement authority:

The Commission also notes that the proposed rule applies to entities beyond the FTC’s traditional jurisdiction under Section 5 of the FTC Act, since the Recovery Act does not limit the FTC’s enforcement authority to its enforcement jurisdiction under Section 5. Indeed, section 13407 of the Recovery Act expressly applies to “vendors of personal health records and other non-HIPAA covered entities,” without regard to whether such entities fall within the FTC’s enforcement jurisdiction. Thus, the proposed rule would apply to entities such as non-profit entities that offer personal health records or related products and services, as well as non-profit third party service providers.

(Health Breach Notification Rule pp 6-7)

Section 318.2 defines “breach of breach” as the acquisition of unsecured PHR identifiable health information of an individual without the authorization of the individual. This definition is identical to the definition of “breach of security” found in section 13407(f)(1) of the Recovery Act. Of significant note the term “acquisition”, according to the FTC, “suggests that the information is not only available to unauthorized persons, but in fact has been obtained by them.” (Health Breach Notification Rule at 8). The FTC described a scenario where a technical security breach may have occurred but without acquisition of health information the breach does not meet the definition of “breach of security” under the Rule. The scenario described occurs when an employee inadvertently accesses a database, but realizes that it was not the one he or she intended to view, and logs off without reading, using, or disclosing anything. (Health Breach Notification Rule at 9). There is a presumption that a breach involves an acquisition of health information however:

[T]his presumption can be rebutted with reliable evidence showing that the information was not or could not reasonably have been acquired. Such evidence can be obtained by, among other things, conducting appropriate interviews of employees, contractors, or other third parties; reviewing access logs and sign-in sheets; and/or examining forensic evidence.

(Health Breach Notification Rule at 9)

Section 318.2(f) defining PHR related entities follows the same definition set forth in clauses (ii), (iii), and (iv) of section 13424(b)(1)(A) of the Recovery Act. PHR related entities include (non-HIPAA covered entities) “that access information in a personal health record or send information to a personal health record.” (16 CFR 318(f)).

The term PHR identifiable health information needs clarification. PHR identifiable health information is

“individually identifiable health information,” as defined in section 1171(6) of the Social Security Act (42 U.S.C. 1320d(6)), and, with respect to an individual, information: (1) that is provided by or on behalf of the individual; and (2) that identifies the individual or with respect to which there is a reasonable basis to believe that the information can be used to identify the individual.

(16 CFR 318.2(e)).

The FTC broadly interprets the term identifiable health information as including “the fact of having an account with a vendor of personal health records or related entity, where the products or services offered by such vendor or related entity relate to particular health conditions.” (Health Breach Notification Rule at 12) Examples that under the FTC’s interpretation where breach notification would be required even where no specific health information is disclosed include “the theft of an unsecured customer list of a vendor of personal health records or related entity directed to AIDS patients or people with mental illness.” (Health Breach Notification Rule at 12)

PHR related entity excludes HIPAA-covered entities and business associate of HIPAA-covered entities. However PHR related entities include any entity who offers products or services through the website of a PHR vendor, who offers products or services through the websites of a HIPAA-covered entity that also offers individuals PHRs and any entity that accesses information in a PHR or sends information to a PHR. (16 CFR 318.2(f)). Many organizations will unexpectedly be covered by the FTC’s rather broad interpretation of PHR related entities and PHR identifiable health information if these terms cannot be more strictly defined through the public comment process. (Proposed Regulations Avaliable Here)

A breach will be treated as discovered “as discovered as of the first day on which such breach is known to a vendor of personal health records, PHR related entity, or third party service provider, respectively, including any person (other than the individual committing the breach) (16 CFR 318.3(c)). Notice must be provided without unreasonable delay but no later than 60 days, however, the FTC must be notified within 5 business days where the breach involves more than 500 individuals. (16 CFR 318.4) Where a breach involves less than 500 individuals a PHR related entity must report such incidents in a yearly report to the FTC.

Section 318.9 clarifies that the Rule will sunset when Congress enacts new legislation affecting PHR related entities and third party vendors of PHR vendors.

[1] HIPAA Covered Entities include health care providers, payors and clearinghouses. Under the HITECH Act Business Associates of Covered Entities will also be covered by security breach notification requirements.

Enforcement of Standards for the Protection of Personal Information of Residents of the Commonwealth Delayed Until to January 1, 2010

Robert Hudock Esq CISSP — Wed, 08 Apr 2009 05:09:00 +0000

The Commonwealth of Massachusetts recently extended the date for compliance with the newly issued regulations, entitled Standards for the Protection of Personal Information of Residents of the Commonwealth, 201 CMR 17:00, to January 1, 2010.[1]

The regulations were issued by the Office of Consumer Affairs and Business Regulations (OCABR) and are enforced by the Massachusetts Attorney General.

Generally the following administrative requirements must be met:

(1) The implementation of a security program (which goes beyond merely addressing the IT aspects);

(2) At least one employee to be designated to maintain a comprehensive information security program;

(3) •Ongoing employee training (including temporary and contract employee), ensuring employee compliance, developing security policies for employees (including determining individual levels of access);

(4) •Disciplinary measures for violations of company security policies;

(5) •A process in place for preventing terminated employees from gaining access;

(6) •A process to verify that any third-party service provider with access to personal information have the capacity to protect such information, as well as taking steps to ensure that such third-party service provider is applying such personal information protective security measures. This may require obtaining written assurances from such third-party providers;

(7) The protection of retained covered data and the encryption of transferred data;

(8) Identifying and assessing internal and external risks to the security, confidentiality, and/or integrity of any electronic, paper or other records containing personal information;

(9) Collecting the minimum amount of personal data necessary to accomplish the business purpose for which the data were collected;

a. Inventorying paper, electronic and other records, computing systems, and storage media, including laptops and portable devices used to store personal information, to identify those records containing personal information;

b. Documenting of actions taken in connection with any incident involving a breach of security and mandatory post-incident review of events and actions taken to mitigate the breach; and

c. Continual monitoring (and, when necessary, re-tooling) of that security program.

The regulations also require technical safeguards including:

(1) Patch management such that the current version of system security software which must include antispyware and antivirus software, have up-to-date patches and virus definitions, and software that is set to receive the most current security updates on a regular basis;

(2) Periodic review of audit trails restricted to those with job-related need to view audit trails;

(3) Firewall protection with up-to-date patches, including operating system security patches; and

(4) Restricted physical access to computerized records containing personal information, including a written procedure that sets forth the manner in which physical access to personal information is restricted

The new regulations apply to “all persons who own, license, store or maintain” (either paper or electronic) covered data about a resident of the Commonwealth.

Any company that transacts with a Massachusetts resident (i.e., as customers, such as by taking a credit or debit card transaction and either retaining on a computer or transmitting that data to a third party) or that employs a Massachusetts resident (due to existence of the information contained in employee records, especially where those records are shared with outside accountants, payroll firms, etc.) is covered by the regulation.

The personal data covered by this regulation includes all non-public data. Unlike HIPAA which applies to covered entities (and business associates under the HITECH Act or by contract), all data obtained regardless of how the company obtained the information must comply with the new regulations on or before January 1, 2010.

Covered indentifies (similar to other state security breach laws) include:

(1) A Massachusetts resident’s first and last name or an initial with last name; and

(2) Anyone of the following

(a) Social Security Number;

(b) Driver’s license number/state-issued identification card number; or

(c) Financial account number/credit card number/debit card number, even if without any security code, access code, PIN or password.

A company is under an obligation to implement a comprehensive written information security program that is reasonably consistent with industry standards. The company must put various safeguards (administrative, technical, and physical) in place to protect the personal data of employees and customers. Further, all employees of the business are to be made aware of this written program. As to the specific measures necessary to be in compliance, a given company’s obligations will vary on a case by case basis depending upon the nature of the business and the type of data involved.

This regulations are enforced by the Massachusetts Attorney General’s Office. A company found to be in non-compliance may be subject to:

(1) An action to enjoin the conduct found to be in violation;

(2) A fine payable to the state of up to $5,000 per “method, act or practice” that the business knew or should have known violated the regulations; and

(3) The imposition of costs associated with any litigation, including reasonable attorney’s fees.

[1] 201 CMR 17.00 – 17.04 (available at http://www.mass.gov/?pageID=ocaterminal&L=4&L0=Home&L1=Consumer&L2=Privacy&L3=Identity+Theft&sid=Eoca&b=terminalcontent&f=reg201cmr17&csid=Eoca).

The Nuts and Bolts of EHRs and Interoperability

Robert Hudock Esq CISSP — Mon, 06 Apr 2009 04:35:00 +0000

There is a surreal level of excitement this year at HIMSS’s annual conference. The recent passage of the HITECH Act promises billions of dollars to providers for the implementation of an EHR system. A record number of EHR vendors have applied for CCHIT certification in hope that this will be the new Federal Standard. (See cchit.org/about/news/releases/2009/Certification-Commission-Experiences-Surge-in-Applications.asp.) Vendors, providers, credentialing organizations and consultants are trying to divine precisely how to meet yet undefined Federal standards for the implementation of EHR systems. Electronic health records in some form have been around for some time however, the challenge of interoperability of these systems remains unresolved. Interoperability currently is and will likely continue to be a key requirement to receive any payments under the HITECH Act for the implementation of an EHR system, however, an unrealistic focus on universal interoparability will only impair the impelmentation/ impede of EHR systems.

HIMSS defines an electronic health record as-

a longitudinal electronic record of patient health information generated by one or more encounters in any care delivery setting. Included in this information are patient demographics, progress notes, problems, medications, vital signs, past medical history, immunizations, laboratory data and radiology reports. The EHR automates and streamlines the clinician's workflow. The EHR has the ability to generate a complete record of a clinical patient encounter - as well as supporting other care-related activities directly or indirectly via interface - including evidence-based decision support, quality management, and outcomes reporting..

(http://www.himss.org/ASP/topics_ehr.asp).

In the Electronic Healthcare Record world "HL-7" is the most common standard in use today to define the content of a message or a packet of health information belonging to someone's EHR record. On a macro scale HL-7 is a significant advancement over more traditional models of interoperability including paper and scanned documents. HL-7 is the next level sophistication, machine organizable data files (e.g. comma delimited files). (See Table 1 below). The most common communication standard in use today by EHR's is called HL-7 version 2. HL-7 version 2.x is a protocol defining how to format and represent medical information from many different sources. Seven in HL-7 refers to the protocol layer within the OSI (Open Systems Interconnection Reference Model). Other common (Layer 7) Application layer protocols include FTP, Bittorent, Lightweight Directory Access Protocol ("LDAP"), and Simple Object Access Protocol ("SOAP"). SOAP is functionally similar to HL-7. SOAP is a protocol specification for exchanging structured data using Extensible Markup Language (XML) as the message format, and other level 7 protocols including Remote Procedure Call (RPC) and HTTP. ANSI X12 refers to Electronic Data Interchange (EDI) standards developed by ANSI (American National Standards Institute). Those familiar with the HIPAA Transactions and Codeset Regulations may also be familiar with X12. The following X12 EDI transaction formats are mandated under HIPAA: 270 Eligibility, Coverage, or Benefit Inquiry 271 Eligibility, Coverage, or Benefit Information 276 Health Care Claim Status Request 277 Health Care Information Status Notification 278 Health Care Services Review Information 820 Payment Order / Remittance Advice 834 Benefit Enrollment & Admittance 835 Health Care Claim Payment/Advice 837 Health Care Claim (separate IGs for Dental, Institutional, or Professional).

**OSI Seven Layer Network Model**
Protocol Layer	Description	Data Unit
Layer 7 - Application	Network process to application	Data
Layer 6 - Presentation	Data representation and encryption	Data
Layer 5 - Session	Interhost communication	Data
Layer 4 - Transport	End-to-end connections and reliability	Segment
Layer 3 - Packet	Path determination and logical addreessing	Packet
Layer 2 - Data Link	Physical addressing	Frame
Layer 1 - Physical	Media, signal and binary transmission	Bit

A sample HL-7 message (relating to a patient’s immunization data) is illustrated by the following:

MSH|^~\&||GA0000||VAERSPROCESSOR|20010331605||ORU^RO1|20010422GA03|T|2.3.1|||AL|PID|||1234^^^^SR~1234-12^^^^LR~00725^^^^MR||Doe^John^Fitzgerald^JR^^^L||20001007|M||2106-3^White^HL70005|123 Peachtree St^APT 3B^Atlanta^GA^30210^^M^^GA067||(678) 555-1212^^PRN|NK1|1|Jones^Jane^Lee^^RN|VAB^Vaccine administered by (Name)^HL70063|NK1|2|Jones^Jane^Lee^^RN|FVP^Form completed by (Name)-Vaccine provider^HL70063|101 Main Street^^Atlanta^GA^38765^^O^^GA121||(404) 554-9097^^WPN|ORC|CN|||||||||||1234567^Welby^Marcus^J^Jr^Dr.^MD^L|||||||||Peachtree Clinic|101 Main Street^^Atlanta^GA^38765^^O^^GA121|(404) 554-9097^^WPN|101 Main Street^^Atlanta^GA^38765^^O^^GA121|OBR|1|||^CDC VAERS-1 (FDA) . . .

I have omitted the rest of the sample HL-7 sample message to save space (however this example and others can be found at http://www.dt7.com/cdc/sampmsgs.html). Those who are familiar with comma delimited files in Excel or simple database exports may find the above example familiar. An HL-7 message is a collection of data related to a health-care event. The communication connection between two computers sending HL7 messages is called an interface. For the more technically inclined an-open source HL-7 programming interface and HL-7 parser can be found at http://hl7api.sourceforge.net/. HL-7 version 3 is meant to make the leap to the final level of interoperability from version 2

Table 1 Interoperability Level by Data Type[1]

Method	Context
Non-electronic data Paper, mail, and phone call.	Traditional method had been in use of 100+ years.
Machine transportable data Fax, email, and unindexed documents.	Scanned Documents, rudimentary searching capacity of OCR’ed documents.
Machine organizable data (structured messages, unstructured content) HL7 messages and indexed (labeled) documents, images, and objects.	Current Standard. HL7 Version 2.x (a delimited text file); highly flexible but poor interoperability.
Machine interpretable data (structured messages, standardized content) Automated transfer from an external lab of coded results into a provider’s EHR. Data can be transmitted (or accessed without transmission) by HIT systems without need for further semantic interpretation or translation.	Future Standard. HL7 Version 3, less flexible but designed to result in interoperable EHR systems.

HL-7 version 3 (per the official website http://www.hl7.org/) is meant to replace the free form ad-hoc approach and flexibility that defines HL-7 version 2. Unfortunately the flexibility of version 2 has come at a cost, the design has hindered interoperability with a more rigid structure of version 3 should solve interoperability issues encountered within HL-7 version 2.

[Version 2] [w]hile providing great flexibility, its optionality also makes it impossible to have reliable conformance tests of any vendor's implementation and also forces implementers to spend more time analyzing and planning their interfaces to ensure that both parties are using the same optional features. Version 3 addresses these and other issues by using a well-defined methodology based on a reference information (i.e., data) model. It will be the most definitive standard to date. Using rigorous analytic and message building techniques and incorporating more trigger events and message formats with very little optionality, HL7's primary goal for Version 3 is to offer a standard that is definite and testable, and provide the ability to certify vendors' conformance. Version 3 uses an object-oriented development methodology and a Reference Information Model (RIM) to create messages. The RIM is an essential part of the HL7 Version 3 development methodology, as it provides an explicit representation of the semantic and lexical connections that exist between the information carried in the fields of HL7 messages.

(see http://www.hl7.org/index.cfm version 3 messaging standard)

HL-7 covers a broad range of health related activities (as illustrated by Table 2).

Table 2 - Typical HL-7 Data Categories

Category	Description
Patient Administration	Admit, Discharge, Transfer, and Demographics.
Order Entry	Orders for Clinical Services and Observations, Pharmacy, Dietary, and Supplies.
Financial	Patient Accounting and Charges.
Observation	Observation Report Messages.
Scheduling	Appointment Scheduling and Resources.
Patient Referral	Primary Care Referral Messages.
Patient Care	Problem-Oriented Records.

With HL-7 version 3 we may have the language and grammar for describing an electronic health record, however, we still have difficulty in visualizing (mentally incorporating the concept of) a medical record that exists as an abstraction of relationships between health care related objects each combination of objects differing from patient to patient as the medical condition and treatments for any given individual varies. This intellectual obstacle is illustrated by one presenters comment on the topic of e-discovery of health care records– that the only way to produce a “legal” medical record is by producing electronic images of the paper files. The extreme variation within HL-7 version 2 implementations illustrate the most fundamental problem of interoperability: if two organizations are using different variations of the HL-7 standards, the entities will be unable to communicate. Specialized interfaces -- programs the translate between two different standards -- can be implemented on a case by case basis however this solution is not scalable and requires continuous maintenance and testing to ensure that the system is reliable.

Many believe semantic ontologies are required for effective interoperability. Ontology is a philosophical concept that for our purposes can be viewed as a formal representation (abstraction) of a set of concepts (objects) within a domain and the relationships between those concepts. Ontologies are used to reason about the properties of that domain, and may be used to define the domain. Ontologies include Individual instances or objects; classes which are sets or collections of objects; attributes that define properties, characteristics, or parameters of an objects (or class); relations between classes and individual objects to one another; and events that change attributes or relations of objects or classes. However, ontological based machine learning has remained an unsolvable problem for the last 60 years. We will likely have to accept that universal interoperability will not be possible for some time to come.

"I do not pretend to start with precise questions. I do not think you can start with anything precise. You have to achieve such precision as you can, as you go along." Quotation of Bertrand Russell

[1] NAHIT Levels of EHR Interoperbility. "What is interoperability?". National Alliance for Health Information Technology. Retrieved on 2007-04

Analysis of the HITECH Act’s Incentives to Facilitate Adoption of Health Information Technology

Robert Hudock Esq CISSP — Sun, 08 Mar 2009 22:58:00 +0000

By Robert Hudock

The “Health Information Technology for Economic and Clinical Health Act’’ or the ‘‘HITECH Act” (as contained within the American Recovery and Reinvestment Act of 2009 [the “Stimulus”]) will expand the use of health information technology (HIT) and appropriates $250 million for this Fiscal Year for implementing the new HITECH provisions.1 Politicians are now convinced that health care expenditures can be tamed using HIT: Health care expenditures currently make up 16% of the U.S. gross domestic product and are projected to become about 20% of the gross domestic product by 2015.2 The HITECH Act thus offers significant financial incentives to providers for implementing HIT, in particular, electronic health records (EHR).

The Goals of the HITECH Act

The HITECH Act is intended to encourage more effective and efficient health care through the use of technology, thereby reducing the total cost of health care for all Americans and then using these savings to enable all Americans to have access to the health care system. Savings are expected to come from efficiency gains and improved clinical guidelines, allowing treatments to be standardized for various medical conditions.3

The stated goals of the HITECH Act include implementation of:

A national health technology infrastructure (including both hardware and software) to ensure the electronic exchange, use and integration of health information including comparative effectiveness data;
An electronic health record for each person in the United States by 2014;
A framework for coordination and flow of recommendations and policies among the Secretary, the National Coordinator, the HIT Policy Committee, the HIT Standards Committee, and other relevant entities;
Mechanisms to foster the public understanding of health information technology;
Strategies to enhance the use of health information technology with an eye towards improving the quality of health care, reducing medical errors, reducing health disparities, improving public health, increasing prevention and coordination with community resources; and
Guidelines to improve the continuity of care among health care settings.

Title XIII—Health Information Technology

Part A – Promotion of Health Information Technology

The United States is set to invest significant resources into health information technology over the next seven years, with the expectation that every citizen will have an electronic medical record by the year 2014. To accomplish this herculean effort, the HITECH Act implements a new administrative structure within HHS to manage the implementation of HIT technology at a national level. Key administrative persons and committees created by the HITECH Act are the National Coordinator for the Office of the National Coordinator for Health Information Technology (ONCHIT), the HIT Policy Committee responsible for defining key policies for the implementation of a national health information infrastructure, and the HIT Standards Committee to assess standards, implementation specifications, and certification criteria for HIT.

The National Coordinator is responsible for coordinating HIT policies and programs, developing a voluntary HIT certification program, and setting milestones for utilization of EHRs for each person in the United States by 2014.
The HIT Policy Committee is responsible for recommending areas where standards, implementation specifications and certification criteria are needed for the electronic exchange and use of health information. The HIT Policy Committee sets the priority for the development, harmonization, and recognition of standards, specifications, and certification criteria. This committee will also identify standards, architectures, and software schemes for maintaining the confidentiality of identifiable health information and to ensure a common solution across an array of different healthcare entities.
The HIT Standards Committee is responsible for recommending to the National Coordinator standards, implementation specifications, and certification criteria for the electronic exchange and use of health information and to serve as Forum where key stakeholders can provide input on the development, harmonization, and recognition of standards, implementation specifications, and certification criteria for a nationwide health information technology infrastructure. The HIT Standards Committee is responsible for ensuring that HIT standards and implementation specifications meet the policy goals set by the HIT Policy Committee. Within 90 days after the enactment of the Stimulus, the HIT Standards Committee is required to release a schedule for the assessment of policy recommendations developed by the HIT Policy Committee pursuant to section 3002 of the HITECH Act.

Along with the creation of a new national HIT administrative structure to facilitate adoption of Health Information Technology, the HITECH Act also provides incentives to promote use of EHRs, telemedicine, and clinical data repositories. These incentives are discussed below. In many instances, previous government attempts to encourage EHR have been less than satisfactory. Unlike earlier initiatives, the new program offers both a carrot and stick approach.

Part B – Testing of Health Information Technology

Part B directs coordination of testing of HIT standards and implementation specifications in cooperation with the National Institute of Standards and Technology (NIST). NIST and the NSF are to establish a grant-funded research program to assist universities (and others) to establish Multidisciplinary Centers for HIT related research to be coordinated with the National Information Technology Research and Development Program. Research areas include:

Interfaces between human information and communications technology systems;
Voice-recognition systems;
Software that improves interoperability and connectivity among health information systems;
Software dependability in systems critical to health care delivery;
Measurement of the impact of information technologies on the quality and productivity of health care;
Health information enterprise management;
Health information technology security and integrity; and
Relevant health information technology to reduce medical errors.

(Section 13202(4), Section 13202(5) of the Act.)

Part C – Grants and Loan Programs

Under the Stimulus, $2.1 billion has been allocated for the development of standards, investment in Health Information Exchange Technology, and grants distributed by the Office of the National Coordinator of Health IT (“ONCHIT”) to states to assist with the adoption of EHR technology.
The Secretary is directed to spend appropriated funds through various federal agencies, including ONCHIT, HRSA, AHRQ, CMS, CDC and the Indian Health Service to support:

Development of the architecture for nationwide electronic exchange;
Development and adoption of “certified EHR technology” (defined to require interoperability);
Funding the adoption of EHR technology for certain providers not otherwise eligible for support under the Medicare or Medicaid Programs;
Training and dissemination of information on best practices, telemedicine infrastructure, interoperability of clinical data repositories, promotion of privacy and security, and
Expansion of personal health record use of HIT.

The Secretary of HHS is directed (by the HITECH Act) to support the development of HIT Regional Extension Centers, to be affiliated with US-based nonprofit organizations. These centers will apply for and be awarded financial assistance under this part of the Act. This financial assistance may be awarded for up to four years and may not exceed 50 percent of the capital and annual operating funds required to create and maintain the Center. (Section 13202 of the Act.)
The Secretary is also directed to establish a program to provide planning grants and implementation grants to a state or “qualified state designated entity” for the purpose of advancing the interoperable use of EHRs. These grants will require matching cash or in-kind contributions from the host state as follows: in 2011, $1 state to $10 federal; in 2012, $1 state to $7 federal; and in 2013 and thereafter, $1 state to $3 federal. The Secretary has discretion to require a state match for grants awarded prior to 2011.

ONCHIT may also award competitive grants to states (and Indian Tribes) to seed “certified EHR Technology loan funds” for the purpose of facilitating the purchase and utilization of “certified EHR technology.” These grants will require private or state matching funds of not less than $1 for every $5 of federal funds.

Title IV – Medicare and Medicaid Health Information Technology; Miscellaneous Medicare Provisions

The HITECH Act provides incentives under either Medicare or Medicaid for providers who have adopted EHR systems determined to meet the Secretary’s relevant guidance and statutory requirements for meaningful use: those providers can receive bonus payments starting in 2011. “Meaningful use” of an EHR includes three key components: (1) the EHR must be certified and include ePrescribing capabilities; (2) the technology must provide for the electronic exchange of personal health information with other systems (interoperability); and (3) the system must produce reports utilizing various (yet to be defined) clinical and quality metrics (Section 4101(a)(o)(2) of the HITECH Act). Under the HITECH Act, $17 billion has been set aside for incentive payments to providers who implement a qualifying EHR under either Medicare or Medicaid. However, the provider cannot double dip; a provider may only seek incentive payments under either Medicare or Medicaid but not both.

Certified EHR technology is defined to include EHRs which have been deemed qualified in accordance with the necessary standards and implementation specifications as established under the Act. The National Coordinator is tasked with the development of qualified electronic health record technology (i.e. a certification system) for EHRs. The criteria for certification are to be developed under Section 3001(c)(3) of the Act.

Professionals who are hospital-based are not eligible for the incentive payments. Hospital-based professionals include pathologists, anesthesiologists, and emergency physicians who furnish substantially all of her/his services in a hospital setting (either inpatient or outpatient). These physicians would use the hospital’s EHR. Hospitals are also entitled to a separate set of incentive payments under the law. Whether an eligible professional is hospital-based is determined by the billing or employment arrangements between the provider and the hospital.

Medicare Incentives for Physicians

Unlike the Medicaid incentives, bonus payments under the HITECH Act for physicians seeking Medicare incentives are all the same flat amount based on the year in which the provider places in service a qualifying EHR. No incentive payments will be provided before 2011 and after 2016 (Section 4101(a)(o)(2)(A)(ii) of the HITECH Act).
Table 1 – Physician Incentives under Medicare

Year	2011	2012	2013	2014	2015	2016	Max Bonus Payment
2011	$18,000.00	$12,000.00	$8,000.00	$4,000.00	2,000.00	$-	$44,000.00
2012	$-	$18,000.00	$12,000.00	$8,000.00	$4,000.00	$2,000.00	$44,000.00
2013	$-	$-	$15,000.00	$12,000.00	$8,000.00	$4,000.00	$39,000.00
2014	$-	$-	$-	$12,000.00	$8,000.00	$4,000.00	$24,000.00
2015	$-	$-	$-	$-	$-	$-	$-

Incentive payments will be increased by 10% if the provider predominantly serves beneficiaries in any area designated as a Health Professional Shortage Area (“HPSA”). If an eligible professional was not a meaningful user, then the fee schedule amount for such services furnished by the professional during the year shall be equal to the applicable percent of the fee schedule amount as follows. The discount amounts are as follows: for 2015, 99%; for 2016, 98%; and for 2017 and each subsequent year, 97%. The percentages can be decreased on and after 2018 based upon the proportion of eligible professionals who are meaningful users.

Medicare Incentives –Hospitals

Beginning in 2011, incentives payments are available for “eligible hospitals” that are making meaningful use of an EHR and that submit quality metrics based on criteria identified by HHS. (Section 4102(n)(2)(G), Section 4102(n)(3)) Hospital payments are based on a $2 million base amount. Added to the base amount is an additional discharge-related payment multiplied by the hospital’s Medicare share. Incentive amounts are phased out beginning in 2015 for hospitals that not implemented a meaningful EHR and are not producing clinical quality data. The details of the actual bonus payment available to hospitals under this provision are complicated. The incentive payment for an eligible hospital is equal to the sum of the $2 million base amount (Section 4102(n)(2) plus the product of discharge amount for a 12-month period and the hospital’s Medicare share. The sum of the base amount and the product of the discharge amount and the Medicare share are then multiplied by a transition factor. (1 [year 1], .75 [year 2], .5 [year 3], and .25 [year 4]). (Section 4102(n)(2)(E))

Calculating the Discharge Amount: The discharge amount is calculated by summing the total discharges beginning with the 1,150th discharge through the 23,000th discharge. The sum of discharges above 1,150 but below 23,001 for the hospital is then multiplied by $200. (Section 4102(n)(2)(C))
Calculating the Medicare Share: The Medicare share is calculated by summing the number of inpatient-bed-days attributable to individuals for whom payment is made under Medicare part A and under a Medicare Advantage plan part C. (In the absence of Medicare specific in-patient data this amount is assumed to be zero.) This sum is then divided by the product of:
- The total number of inpatient-bed-days for the hospital during the 12-month period; and
- The total amount of eligible hospital charges during the period (excluding charges that are attributable to charity care) divided by total amount of the hospital’s charges during the same period. (Section 4102(n)(2)(D)). (In the absence of data for charges for Medicare patients this amount is assumed to be one.)

Starting in 2015, any “eligible hospitals” failing to turn in the required quality data will also be subject to a reduction in their annual reimbursement rate updates.

Medicaid Incentives

Physicians who seek bonus payment under the Medicaid incentive program can potentially receive a maximum of $64,000. The Medicaid incentive structure is more complicated than Medicare and contains certain restrictions.
A health care provider is eligible for incentives under Medicaid if the provider:

Is not hospital-based and his/her practice consists of at least 30% Medicaid patients by volume; and
Is not hospital based, is a pediatrician and his/her practice consists of at least 20% Medicaid patients by volume;

Providers would be eligible for reimbursement of 85 percent of allowable EHR costs, not to exceed a maximum (per provider) of $63,750. Note that hospitals with at least 10 percent Medicaid patient volume would be eligible for an incentive payment based on a formula similar to the calculation for incentive payments provided for under the Medicare economic incentive.

Cautious Approach When Adopting EHR

Because of the possibility of financial benefit, for small and large
providers alike, the implementation of an EHR likely will be a top
priority over the next two years; however, financial benefits will not
be realized without navigating a bureaucratic obstacle course and until
a critical mass of providers have adopted interoperable EHRs.. (See www.ischool.drexel.edu/faculty/ssilverstein/failurecases/?loc=cases&sloc=secrets for one physician’s experience and opinion).5

Recent studies highlight the need for a critical mass of provider adoption before benefits can be realized from EHRs. Some studies primarily done in smaller provider settings show that implemented EHR systems have serious issues. Some clinical studies that have looked at whether EHRs increase the quality of care for patients (within non-integrated providers) have raised concerns about the effectiveness of EHRs to create new efficiencies and increase the quality of care. However, research done with larger integrated service providers found evidence of increased efficiency and quality of care:

Properly implemented and widely adopted, Health Information Technology would save money and significantly improve healthcare quality;
Annual savings from efficiency could be $77 billion or more;
Health and safety benefits could double the savings while reducing illness and prolonging life; and
To be effective implementation must be widespread to realize network effect efficiencies.

One study of particular note identified four classes of trajectory-changing events. The identification and management of such events was made possible in part by the use of health information technology. Four noted interventions that resulted in both efficiency and quality gains included:

Computerized Physician Order Entry (CPOE) reduced adverse drug events (ADEs) thereby reducing the length of stays in the hospital;
The provision of the influenza and pneumococcal vaccinations, as well as screening for breast, cervical, and colorectal cancer. Many hospitalizations can be avoided with proper vaccinations, while more pervasive screening identifies cancers earlier, improving both survival and allowing less costly treatments to be utilized;
Enrolling people with chronic conditions (including asthma, chronic obstructive pulmonary disease (COPD), congestive heart failure (CHF), and diabetes) in disease management programs saves significant resources and improves the patient’s quality of care; and
Monitoring and encouraging patients to control their weight, stop smoking, exercise, and control their blood pressure and cholesterol with medications.

The estimated effects of HIT on health care utilization are dependent on having a critical mass of providers. At the critical mass point, the value obtained from an EHR is greater than or equal to the cost. The failure to achieve a critical mass likely accounts for the differences between the utility of EHRs within integrated and non-integrated provider settings. Hopefully, the government’s incentives will spur a critical mass of providers to adopt EHRs; otherwise the financial incentives will not be sufficient—in and of themselves—to realize the promise of a national HIT infrastructure.

1 The $787 billion Stimulus was signed into law on February 17, 2009 by President Obama.

2 Christine Borger, Sheila Smith, Christopher Truffer, Sean Keehan, Andrea Sisko, John Poisal and M. Kent Clemens. Health Spending Projections Through 2015: Changes On The Horizon. Health Affairs, 25, no. 2 (2006): w61-w73 (Published online 22 February 2006)(available at content.healthaffairs.org/cgi/content/full/25/2/w61)

3 Girosi, F., Melti R., and Scoville, R., Extrapolating Evidence of Health Information Technology Savings and Costs (© 2005 Rand Corporation)(available at http://www.rand.org/pubs/monographs/2005/RAND_MD410.pdf).

4 Title IV, Subtitle A, Section 4101(a) of Health Information Technology for Economic and Clinical Health Act’’ or the ‘‘HITECH Act”.

5 Concerns of providers that have implemented EHRs include:

The cost of EHR technology, the lack of consistent pricing, and the inability to recoup costs hinder implementation of HIT. (It is not clear whether financial incentives under the HITECH act will be sufficient to offset the costs of implementing an EHR for a typical physician practice);
CCHIT requires features that add significantly to cost while raising privacy and data security concerns of physicians;
EHRs lack interoperability, and the cost associated with trying to connect to other computer systems is significant, usually requiring custom development to allow for interoperability;
Loss of productivity when converting from a paper-based to an electronic practice is significant; and
Comparative effectiveness research may undermine individual-specific care when comparative effectiveness data are used as the basis for “standards” by all payors (including Medicare). Ultimately could these new Federal standards provide the basis for determining medically necessity? (See http://www.ischool.drexel.edu/faculty/ssilverstein/failurecases/?loc=cases&sloc=secrets).

6 CCHIT certification has hundreds of specific criteria defining how an EHR must work. Every implementation specification is required for certification, causing a CCHIT-certified EHR to become blotted by all the required “features”. Some examples of their onerous requirements include: criteria #71a, which mandates the EHR be capable of recording comments by the patient or patient’s representative regarding the veracity of information in the patient record; and criteria #238 which requires an EHR to be able to display medical eligibility obtained from a patient’s insurance carrier.

7 “For 14 of the 17 quality indicators, there was no significant difference in performance between visits with [versus visits] without EHR use. Categories of these indicators included medical management of common diseases, recommended antibiotic prescribing, preventive counseling, screening tests, and avoiding potentially inappropriate medication prescribing in elderly patients. For 2 quality indicators, visits to medical practices using EHRs had significantly better performance: avoiding benzodiazepine use for patients with depression (91% vs 84%; P = .01) and avoiding routine urinalysis during general medical examinations (94% vs 91%; P = .003). For 1 quality indicator, visits to practices using EHRs had significantly worse quality: statin prescribing to patients with hypercholesterolemia (33% vs 47%; P = .01).” Linder JA, Ma J, Bates DW, Middleton B, Stafford RS. Electronic health record use and the quality of ambulatory care in the United States. Arch Intern Med. 2007 Jul 9;167(13):1400-5.(Summary available at http://archinte.highwire.org/cgi/content/abstract/167/13/1400).

8 Jesse C. Crosson, PhD, Pamela A. Ohman-Strickland, PhD, Karissa A. Hahn, MPH3, Barbara DiCicco-Bloom, RN, PhD, Eric Shaw, PhD, A. John Orzano, MD, and Benjamin F. Crabtree, PhD. Electronic Medical Records and Diabetes Quality of Care: Results From a Sample of Family Medicine Practices. Annals of Family Medicine 5:209-215 (2007) (Available at http://www.annfammed.org/cgi/reprint/5/3/209).

American Recovery and Reinvestment Act: Overview of Modifications to the HIPAA Privacy and Security Regulations

Robert Hudock Esq CISSP — Wed, 18 Feb 2009 03:19:00 +0000

This alert provides a brief overview of privacy and security provisions included within “The American Recovery and Reinvestment Act of 2009” (H.R.1, S.1) (the “Stimulus”). The Stimulus also includes funding for health information technology (“HIT”) and funding for comparative effectiveness research. These provisions will be the subject of future alerts. Future alerts will also provide analysis and risk management suggestions related to the changes outlined below.

The Stimulus also expands enforcement and the scope of businesses covered by the Health Insurance Portability and Accountability Act of 1996 (HIPAA) Privacy and Security regulations. The expanded privacy and security provisions contained within the Stimulus are expected to have a "significant impact" on a wide range of organizations that deal with, retain, use, and/or create protected health information. The privacy and security provisions are outlined in Table 1.

Table 1 Subtitle D, Part I - Improved Privacy Provisions and Security Provisions

Sec. 13400 – Definitions		Subtitle D - Privacy
Sec. 13401 – Application of security provisions and penalties to business associates of covered entities; annual guidance on security provision	Part I – Improved Privacy Provisions and Security Provision
Sec. 13402 – Notification in the case of breach
Sec. 13403 - Education on health information technology privacy
Sec. 13404 – Application of privacy provisions and penalties to business associates of covered entities
Sec. 13405 – Restrictions on certain disclosures and sales of health information; accounting of certain protected health information disclosures; access to certain information in electronic format
Sec. 13406 – Conditions on certain contracts as part of health care operations
Sec. 13407 – Temporary breach notification requirement for vendors of personal health records and other non-HIPPA covered entities
Sec. 13408 – Business associate contracts required for certain entities
Sec. 13409 – Clarification of application of wrongful disclosures criminal penalties
Sec. 13410 – Improved enforcement
Section 13411 – Audit

Expanded Definition of Business Associate

The legislation extends the application of the main provisions of the HIPAA Security and Privacy regulations to business associates (Section 13401(a)), and contains revised civil and criminal penalties for violation of the HIPAA Privacy and Security Regulations (Section 13401(b)). The legislation also requires the Secretary of HHS to conduct periodic compliance audits of business associates as well as covered entities (Section 13401(c)).

The legislation also expands the definition of business associates to include organizations that provide protected health information as a data transmission service and those that require access to protected health information on a routine basis, as well as vendors who contract with covered entities to offer personal health records (PHR) to patients (Section 13408). The provisions of the Section 13408 became effective on enactment of the Stimulus. Vendors of personal health records (see e.g. http://www.google.com/intl/en-US/health/about/), entities that offer products or services through the website of a vendor of personal health records, entities that access or send information in a personal health record, and third party vendors of these entities must also comply with the HIPAA Privacy and Security Regulations (Section 13424(b)(1)(A)).

Security Breach Notification Requirement

The Stimulus includes a requirement for security breach notifications similar in form and effect to laws passed by most states, including California. Section 13400 defines breach as “the unauthorized acquisition, access, use, or disclosure of protected health information which compromises the security or privacy of such information.” The definition of breach excludes situations where the-

Unauthorized person to whom such information was disclosed would not reasonably have been able to retain such information; and
Information received as a result of such disclosure is not further acquired, accessed, used, or disclosed without proper authorization.

Absent an applicable state law, prior to this legislation, a covered entity was not required to notify individuals of privacy or security breaches unless the covered entity determined that such notification was necessary to mitigate damage to the individual. However, the Stimulus will require covered entities and business associates to notify both individuals and the Secretary of the Department of Health and Human Services (HHS) of "unsecured protected health information" breaches. In the event that the breach affects more than 500 individuals, notification must be made to prominent media outlets serving the state or jurisdiction in which the individuals reside. The Secretary is also required to post the notification on the HHS website.

"Unsecured protected health information" is defined, within section 13402(h)(1)(A), as protected health information (PHI) not secured through the use of a technology or methodology specified by the Secretary of HHS. The Secretary is required to issue and annually to update guidance specifying technologies and methodologies that render PHI "unusable, unreadable, or indecipherable to unauthorized individuals" (Section 13402(h)(2)). If the Secretary fails to issue this guidance within 60 days of enactment, the technology standard applied will be developed or endorsed by a standards developing organization accredited by the American National Standards Institute.

Secretary of Health and Human Services shall promulgate interim -final regulations within 180 days of the enactment of the Stimulus (enacted February 17, 2009). The new security breach notification requirements, within Section 13402, apply to breaches that are discovered 30 days after the date of publication of the interim-final regulations by the Secretary (Section 13402(j)). Similar security breach notification requirements, within Section 13407, become effective to vendors of personal health records (PHRs) to breaches that are discovered 30 days after the date of publication of interim final regulations (Section 13407(g)(1).

Table 2 (below) summarizes other key changes applicable to covered entities and now business associates in complying with the revised HIPAA Privacy regulations. The provisions of Subtitle D, Part I of the Stimulus Act, entitled “Improved Privacy Provisions and Security-Provisions”, unless otherwise specified become effective 12 months after enactment (Section 13423).

Table 2 Modifications to the HIPAA Privacy Regulations

Requirement	Prior to Stimulus	After the Stimulus	Relevant Cite
Right of Individual to Limit Access to PHI	Prior to the Stimulus, an individual had the right to request that the covered entity restrict certain disclosures of PHI, but the covered entity was not required to agree to the restriction.	A covered entity must comply with the individual’s request to limit access to his/her PHI. This provision does not apply to the disclosure of PHI to a health plan for payment or health care operations where the health care provider has not been paid out of pocket in full.	Section 13405(a)
Minimum Necessary Standard	HIPAA privacy rule required covered entities to apply a minimum necessary standard to uses and disclosures of and requests for PHI.	The Stimulus requires the Secretary to issue guidance on what constitutes "minimum necessary" within 18 months after enactment. Provisions of this section apply six months after the date of the promulgation of final regulations.	Section 13405(b)
Accounting Requirement	The HIPAA privacy rule's accounting requirement did not include PHI disclosures for treatment, payment and health care operations purposes.	If a covered entity uses or maintains an EHR, an individual will have the right to receive an accounting of disclosures made during the three years prior to the date of the request. A "reasonable fee" not greater than the entity's labor costs in responding to the request may be collected from the requesting party. This requirement would be effective as of January 1, 2014 for covered entities that have acquired an EHR prior to a certain date. For covered entities acquiring an EHR after that date, the requirement will be effective on the later of January 1, 2011 or the date the EHR is acquired.	Section 13405(c)
Individual Access to PHI in Electronic Form	Not Applicable	Requires covered entities that use or maintain EHRs to provide access of PHI to individuals in electronic format if requested.	Section 13405(e)(1)

Clarification of Penalties under the HIPAA Privacy and Security Regulations

Section 13410 of the Stimulus provides for a tiered increase of Civil Monetary Penalties (CMP) up to a maximum of 1.5 million dollars depending on aggravating factors. The Stimulus also provides for the enforcement of HIPAA by State Attorney Generals. Many of the key provisions take effect after the enactment of the Stimulus including tiered monetary penalties and expanded enforcement provisions.

A wrongful disclosure under HIPAA (as modified by the Stimulus) occurs when a person obtains or discloses PHI maintained by a covered entity and the disclosing party has not obtained an authorization for the disclosure (Section 13409). The Stimulus requires that any civil monetary penalty or settlement amount collected as a result of a privacy or security rule violation be transferred to the Office for Civil Rights to be used for enforcement of the HIPAA privacy and security rules and also in part to be distributed to those affected by the infraction (Section 13410(e)(1)).

Table 3 Tiered Civil Monetary Penalties

Standard of Culpability	Penalty	Maximum Penalty
Did not know of the violation and by exercising reasonable diligence would not have known of violation	Corrective action without penalty	No penalty--however, subject to discretion of Secretary.
Unknowing Violations	At least $100 per violation	Not to exceed $25,000 in a calendar year
Violation due to reasonable cause, not willful neglect	At least $1000 per violation	Not to exceed $100,000 in a calendar year
Violation due to willful neglect	At least $10,000 per violation	Not to exceed $250,000 in a calendar year
Violation is due to willful neglect and the violation is not corrected within 30 days of the first date the person liable for the penalty knew or should have known that the violation occurred.	At least $50,000 per violation	Not to exceed $1,500,000

Damages are calculated by multiplying the penalty by the number of violations in a calendar year for identical requirements or prohibitions. However, the total shall not exceed the amount of Maximum Penalty (Section 13410(d)(1)-(2)).

State attorney generals now have the authority to bring suit in federal district court against any person violating the rules on behalf of state residents to enjoin further violation or to obtain damages on behalf of such residents (Section 13410(e)). Statutory damages are limited to $100 per violation, not to exceed $25,000 in a calendar year for violations of identical requirements. (Section 13410(e)(1)). The court may award attorney fees to the state. The Secretary has the right to intervene in such actions.

Connecticut and Michigan Require Employer-Employee Privacy Policy

Robert Hudock Esq CISSP — Mon, 26 Jan 2009 03:58:00 +0000

Over
the last year
Employer-Employee “Global” Privacy Policies are becoming more common
place (in-part)
due to recent legislation in Connecticut and Michigan. Until
this recent
legislation, within the United States there were few situations where
an
employee had an independent right to access, inspect, or challenge
information
collected or held by the employer (unlike his/or her counterpart within
the
European Union). Within the European Union employers have
been bound by EU
Directive 95/46/EC entitled the “European Data Protection Directive”.
This directive applies to employment or employee data
collected by an employer
within the European Union or the European Economic Area regardless of
where processed
or stored. Employers when creating an employer-employee
privacy policy should carefully
consider the implications of implementing an overly broad privacy
policy. Data
security breaches, e-Discovery obligations, and the ability to
investigate criminal
or other non-productive activity may be hindered by an unnecessarily
broad
workplace privacy policy.

Connecticut

The
new Connecticut Law 2008
Conn. Pub. Act No. 08-167 (available at http://www.cga.ct.gov/2008/ACT/PA/2008PA-00167-R00HB-05658-PA.htm)
entitled An Act Concerning the Confidentiality of Social
Security Numbers
(which became effective October 1^st, 2008)
requires that: “Any person
who collects Social Security numbers in the course of business shall
create a
privacy protection policy which shall be published or publicly
displayed.”

Under
the Statute “publicly
displayed” includes, but is not limited to, posting on an Internet web
page. The Statute broadly applies to any person who
collect personal
information of another individual (including employees)
during the course
of business. Personal information includes
SSNs, a driver’s license
number, a state identification card, an account number, a credit or
debit card
number, a passport number, a health insurance identification
number. A person
who collects personal information must safeguard
the data, computer
files, and documents containing the information from misuse by third
parties,
and shall destroy, erase, or make unreadable such data, computer files
and
documents prior to disposal.

However,
subsection (c) of the
Statute excludes from the definition of personal information
publicly
available information that
is lawfully made available to the general public from federal, state or
local
government records or widely distributed media.

Under
2008 Conn. Pub. Act No. 08-167
employers (and other individuals who collect this information during
the course
of business) must create and publish or publicly display a privacy
protection
policy. The policy must address how the
organization:

Protects the confidentiality of personal
information (including SSNs);
Prevents the unlawful disclosure
of personal information; and
How the organization limits access
to personal information.

The
new law requires that the
policy should be published or “publicly displayed” including posting
on an Internet webpage; this requirement will likely be satisfied by
following an
employer’s existing policy.

The
Act requires businesses (and
thus, employers) who have personal information
about a person (including
their employees) to safeguard the data and computer files and documents
so that
the information is not misused. Employers (businesses) must
also destroy,
erase, or make unreadable any document, computer file, or data before
disposing
of it.

The
Department of Consumer
Protection (and, in some instances, other departments with limited
jurisdiction) has the power to enforce the statute. But only
intentional
violations can result in a civil penalty of $500 per violation, with a
$500,000
cap on a single event. There is no private right of action;
if an employer
violates the statute, the employer cannot be sued by the individual
whose
information has been released. This Statute however does not
preclude other
claims that may exist.

Michigan

The
Connecticut law follows an
older Michigan law entitled Social Security Number Privacy Act,
Public Act
454 of 2004 (MCL 445.81, et seq.)(available at http://www.legislature.mi.gov/(S(3y5t0345lavsqlvfzg1ph4in))/printDocument.aspx?objName=mcl-act-454-of-2004&version=txt)
which took effect in March 2005. This Act prohibits many uses
of an employee’s
Social Security numbers, and requires that policies be adopted to
ensure that all
uses are lawful and confidential.

The
Michigan Act (among other
things) specifically requires businesses who obtain SSNs in ordinary
course of
business to create a privacy policy that:

Ensures
the SSN’s confidentiality;
Prohibits
the unlawful disclosure of the SSN;
Limits
who has access to the SSN;
Describes
how to properly dispose of SSNs; and
Establishes
penalties for violations of the privacy policy. This privacy
policy must be published in an employee handbook, procedure manual, or
in another similar document.

Similar
to the Connecticut Act, the
Michigan Act also limits businesses from publicly display of all (more
than
four sequential digits of the SSN) or requiring an individual to use or
transmit all (more than four sequential digits of his or her SSN) to
gain
access to an Internet website or network unless the connection is
secure
(encrypted).

Compliance with the Red Flag Rules Not a Problem for Covered Entities with an Existing HIPAA Privacy and Security Compliance Program

Robert Hudock Esq CISSP — Wed, 10 Dec 2008 20:24:00 +0000

Recently there has been significant concern in the health care industry

around providers’ compliance with the Red Flag Regulations. (see e.g., www.ama-assn.org/ama/pub/category/20168.html.) However compliance with these regulations may not be as onerous as what was required under the HIPAA Privacy and Security Regulations. Many of the components of the Red Flag Regulations could effectively be rolled into an existing HIPAA Privacy and Security compliance program. If this structure is already in place, a few modifications to a Covered Entity’s compliance program will likely meet the requirements of the Red Flag Regulations.

Background

In November 2007, the Federal Trade Commission (FTC), the federal bank regulatory agencies, and the National Credit Union Administration (NCUA) promulgated the “Red Flag Regulations,” which implement two sections of the Fair and Accurate Credit Transactions Act (FACTA). The Act was passed by Congress in 2003. Also called the Fair Credit Reporting Act, FACTA’s) principal purpose is to combat identity theft.
The requirements that form the basis of the “Red Flag Regulations” are set forth in 15 U.S.C. §§ 1681m(e) and 1681c(h), which mandate that:

Financial institutions and other creditors develop and follow comprehensive policies to identify and prevent identity theft;

Credit card issuers develop and follow policies for issuing additional or replacement cards in response to a request for such cards made shortly after a change of address notice is received; and

Users of consumer reports develop and follow procedures to verify the identity of a consumer when the address given by the consumer substantially differs from the address contained in the consumer report.

The Regulations do provide more detail as to how to accomplish the above requirements. Under these Regulations, known as the Red Flag Regulations, 16 C.F.R. § 681.1 et seq., financial institutions and creditors of covered accounts must establish a program to detect, prevent and mitigate identity theft.

The FTC’s current interpretation indicates that the Red Flag Regulations apply to many providers in the health care industry. Fortunately, compliance with these new regulations has been delayed. The regulations were originally scheduled to go into effect November 1 of this year (2008). However, on October 24, 2008, the Federal Trade Commission (FTC) wisely decided to suspended enforcement of the Red Flags Regulations until May 1, 2009, to give creditors and financial institutions the time necessary to develop and implement written identity theft prevention programs.

For health care providers, the Red Flag Rules apply to two categories of activities:

Providing covered accounts to consumers. A covered account is defined as a continuing relationship established by an individual to obtain a product or a service. A covered account includes any account offered or maintained by a creditor designated to cover multiple transactions or payments; and
Using consumer reports for employment verification purposes.

Health care providers may be considered creditors because the regulations apply to any company that provides goods or services without demanding payment at the time of the service. Providers often perform services to a patient before billing for care and being paid for the services rendered. Accordingly, many commentators and the FTC argue that health care providers are creditors subject to the Red Flag Regulations, where the provider does not receive payment at the time of service, and are thus required to establish a program to detect, prevent and mitigate identity theft in relation to their patients’ accounts.

Requirements for a Red Flag Compliance Program

There are four elements that must be included in such a compliance program:

(1)Identifying relevant “red flags” for Covered Accounts and incorporating those red flags into an identity theft prevention policy. A red flag is a pattern, practice or specific activity that indicates the possible existence of identity theft. Examples of red flags provided in the regulations include:[1]

A fraud alert on a consumer report;

A notice of “credit freeze” on a consumer report;

An address discrepancy;

Documents provided by the consumer that have been forged;

The failure of a consumer to be able to provide complete information related to their credit or other general background you would normally expect a consumer to be aware of; and

The return of mail sent to the consumer, even though transactions continue to be conducted.

(2) The creditor must have a procedure in place to check for the red flags (identified above) of identity theft;

(3) The creditor must respond to a potential red flag by, for example, contacting law enforcement, putting a hold on the account, etc.; and

(4) The program (similar to the requirements within the HIPAA Privacy and Security Regulations) must be updated periodically to reflect changes in risk to the customer accounts.

Red Flag Compliance for a HIPAA Covered Entity

Many of the requirements for compliance with the Red Flag Regulations could effectively be rolled into an existing HIPAA Privacy and Security compliance program. For example,

Identifying red flags is essentially identifying threats to consumer accounts, similar to identifying threats to Protected Health Information (PHI) under HIPAA;

Provisions to check for red flags are similar to those required for the auditing called for under the Privacy and Security Regulations with respect to PHI;

The response requirement are similar to the incident response requirements under the HIPAA Security Regulations; and

Finally, in the same way that a HIPAA Covered Entity’s risk analysis must be updated with respect to new risks to PHI, a similar update is also called for under the Red Flag Regulations.

From an administrative perspective there is also significant similarity between HIPAA and the Red Flag Regulations. Section 41.90(e) (entitled Administrative Requirements) list four Administrative requirements:

Obtaining approval of the initial written Program by the board of directors or a committee of the board;
Ensuring oversight of the development, implementation and administration of the Program,
Training staff, and
Overseeing service provider arrangements.

In the HIPAA world high-level approval, oversight and training are required components of a HIPAA Compliance Program. However, the distinction between Service Providers under the Red Flag Regulations and Business Associates under the HIPAA Privacy and Security regulations must be carefully considered to ensure appropriate contractual safeguards are put in place for Covered Accounts.

Section 41.90(f) requires creditors to consider the guidelines in Appendix J and include in the creditor’s compliance program those guidelines that are appropriate. Appendix J gives an example of the type of oversight expected of Service Providers: “a financial institution or creditor could require the service provider by contract to have policies and procedures to detect relevant Red Flags that may arise in the performance of the service provider’s activities, and either report the Red Flags to the financial institution or creditor, or to take appropriate steps to prevent or mitigate identity theft. Fed. Reg. Vol. 72, No. 217, pages 63774-5 (November 9, 2007). In the HIPAA world, this type of oversight is typically exercised by a Covered Entity over a Business Associate in the very same way.

For most health care providers, some thoughtful changes to their current policies and procedures under their existing compliance program for the HIPAA Privacy and Security Regulations should be sufficient to meet the requirements of the Red Flag Regulations. However, it would be in error to carry this analogy to far, while HIPAA is designed to regulate Protected Health Information, the Red Flag Regulations are focused on Covered Accounts. Those individuals that may be Business Associates may not be service providers under the Red Flag Regulations, and the converse may also be true (albeit much less likely in the context of healthcare providers) those that are Service Providers may not be Business Associates under HIPAA.

The following are the minimum requirements of a HIPAA covered entity’s Red Flag compliance program:

1) The board must appoint a Compliance Officer

2) A written “Red Flag” compliance program should be written including:

a) A method for a detecting identity theft;

b) A description of how to respond when a red flag detected;

c) A designation of individuals to be notified when an identity theft occurs;

d) A description of how to prevent identity theft; and

e) A method for making patients aware of Red Flag practices.

3) The board must approve minutes of the compliance officer and the Red Flag program.

Conceptually unifying the regulatory requirements under HIPAA and the Red Flag Regulations, allows a covered entity to use the existing compliance structure in place at most Covered Entities, thereby allowing Covered Entities a relatively easy (but rational) pathway to compliance without breaking the bank. While providers may have accounts that are considered to be covered accounts under the Red Flag Regulations, providers are not financial institutions, as such the safeguards expected for a provider that does not operate as a financial institution other then extending payment options beyond the time of service to a patient is a scenario were identity theft is much less likely.

[1] Common red flags in the medical context could include:

· Records showing medical treatment that is inconsistent with physical examination or medical history as reported by the patient;

· Records showing substantial discrepancies in age, race, and other physical descriptions;

· Questions raised by a patient about an explanation of benefits for service that the patient never received;

· Dispute of a bill by a patient who is a victim of financial forms of identity theft;

· Any formal dispute of services or goods rendered by a provider who is given the specific reason of medical identity theft as the reason for the dispute;

· Blood type discrepancy. (See http://www.worldprivacyforum.org/pdf/WPF_RedFlagReport_09242008fs.pdf.)