HITECH and Business Associate Compliance - The Key Points

The following is an outline of a presentation I've done on new Business Associate compliance and risk issues under the Health Information Technology for Economic and Clinical Health Act (HITECH), the portion of the American Recovery and Reinvestment Act (ARRA) dealing principally with electronic health records (EHRs).

HITECH compliance is both possible and necessary, but needs to be approached with care, a willingness to analyze difficult legislative provisions, and a sense of humor. Professional help is highly recommended. If you are so inclined, an alcoholic beverage after a HITECH work session - not before! - is also recommended.

If you'd like a copy of the presentation let me know and I'll send it along. Good luck!
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

What Is HITECH?

1. Title XIII of the American Recovery and Reinvestment Act of 2009, H.R. 1, Pub.L. 111-5 (February 17, 2009)

a. “ARRA” or “the Stimulus Bill

b. 407 pages

2. Title XIII of ARRA: Health Information Technology for Economic and Clinical Health Act – “HITECH Act”

a. 53 pages

3. Subtitle D: Privacy

a. 21 pages

ARRA was principally intended as stimulus vehicle. HITECH was drafted principally to provide funding for electronic health records (EHRs) and related activities. Subtitle D was added to provide additional legal protections given increased use of electronic systems for healthcare use. My opinion: It was hastily drafted, will be hard to interpret in some cases, and will have unintended consequences.

Compare: HIPAA Administrative Simplification was principally intended for claims processing reform, and wound up reforming healthcare privacy and security.

B. Principal HITECH Concepts (in order of current importance)

1. Extend regulation over key healthcare IT players (Business Associates)

2. Create new security breach notification requirements

3. Increase penalties and tighten enforcement

4. Tighten some PHI use and disclosure limitations

5. Tweak patient/consumer data access rights

C. Business Associates Overview

1. The Old Business Associate (BA) Rules

As a matter of jurisdiction HIPAA applies only to Covered Entities (CE), defined by statute to include health plans, health care clearinghouses and health care providers. See 45 CFR § 160.103

The “Business Associate” (BA) was therefore created to allow CEs to use non-Ces to work with Protected Health Information (PHI) on their behalf, without the PHI losing legal protection. A BA is therefore defined as a person to whom a CE discloses PHI so the person can carry out, assist with, or perform a function or activity on behalf of the CE. 45 CFR § 160.103. BA examples include:

· Claims processing, transcription service, application services providers, utilization review, quality assurance, etc.

· Legal, actuarial, accounting, collections, consulting, accreditation, financial, etc. services

· “Any other function or activity regulated by” HIPAA

2. The Old Business Associate Contracts Rules

A CE may disclose Protected Health Information (PHI) to/allow a BA to create or receive PHI on CE’s behalf upon “satisfactory assurance” BA will “appropriately safeguard” PHI. 45 CFR § 164.502. A “satisfactory assurance” is a Business Associate Contract (BAC) including required provisions (or equivalent memorandum of understanding if governmental entities, plan document provisions if group health plan). 45 CFR § 164.504(e). A BAC must include the following provisions:

· Establish permitted uses/disclosures of PHI by BA on behalf of CE, and may permit it for “proper management and administration” of BA

· Prohibit PHI uses/disclosures not permitted by BAC, or “as required by law”

· BA to use “appropriate safeguards” to prevent non-permitted uses/disclosures of all PHI, and implement “administrative, physical and technical safeguards” to protect confidentiality, integrity, availability of electronic PHI

· Report to CE any non-permitted use/disclosure of PHI, and any “security incident of which [the BA] becomes aware”

· Ensure that BA agents/subcontractors agree to same “conditions/restrictions” as BA, and implements “reasonable and appropriate safeguards to protect it”

· Makes PHI available for individual access and amendment, and provide for accounting of disclosures

· Make BA “internal practices, books and records” available to DHHS for review in determining CE’s HIPAA compliance

· Provide for return/destruction/”escrow” of PHI upon termination of BAC

· Authorize termination of BAC if CE “determines” that BA has “violated a material term” of the BAC

45 CFR §§ 164.314(a), .504(e)

PHI protection is enforced because a CE may be penalized if CE “knew of a pattern of activity or practice” of the BA “that constituted a material breach or violation” of the BAC, unless:

· The CE took “reasonable steps to cure the breach or end the violation” and, “if such steps were unsuccessful:”

· Terminated the BAC, if “feasible,” or if not “feasible” reported the problem to DHHS

45 CFR §.504(e)(1)(ii). HIPAA provides no jurisdiction to penalize BAs.

D. The New HITECH BA Rules: Summary

1. Subtitle D incorporates the following HIPAA regulatory terms incorporated by reference

· Business Associate, Covered Entity, disclose, health care operations, health plan, health care provider, payment, protected health information, use

2. BAs are now required to comply with HIPAA security regulations, and HITECH security requirements

3. BAs required to comply with HITECH privacy requirements

4. HITECH privacy and security requirements incorporated in BACs

5. BAs required to terminate BAC or notify DHHS of CE breach or violation

6. BAs may be audited by DHHS

7. BAs subject to civil and criminal penalties for HIPAA privacy or security regulation violations

E. Business Associates Security Drill-Down

1. BAs are now required to comply with the HIPAA Security Rule:

Sections 164.308, 164.310, 164.312, and 164.316 of [the HIPAA security regulations] shall apply to a business associate of a covered entity in the same manner that such sections apply to the covered entity. The additional requirements of this title that relate to security and that are made applicable with respect to covered entities shall also be applicable to such a business associate and shall be incorporated into the business associate agreement between the business associate and the covered entity.

HITECH § 13401(a)

2. The regulations Included for compliance are the following:

a. 45 CFR §164.308: Administrative safeguards

i. Standard: Security management process

A. Specifications

I. Risk analysis ®: “Accurate and thorough assessment of potential risks and vulnerabilities”

II. Risk management ®: Security measures “sufficient to reduce risks and vulnerabilities,” to ensure confidentiality, integrity and availability, protect against reasonably anticipated threats or hazards, protect against improper uses or disclosures, and ensure workforce compliance

III. Sanction policy ®: Against workforce for failure to comply with security policies and procedures

IV. Information system activity review ®: Regular review of audit logs, access reports, security incident tracking reports

ii. Standard: Assigned security responsibility

A. No separate specification; identify security official responsible for policy and procedure development and implementation

iii. Standard: Workforce security

A. Specifications

I. Authorization and/or supervision (A): Of workforce with access to electronic protected health information

II. Workforce clearance procedure (A): For determination whether access rights are appropriate

III. Termination procedures (A): To end access to electronic protected health information when employment terminated or clearance determined inappropriate

iii. Standard: Information access management

A. Specifications

I. Isolate health care clearinghouse functions (R)

II. Access authorization (A): Policies and procedures to grant users access to system resources allowing access to electronic protected health information (e.g. workstations, transactions, processes)

III. Access establishment and modification (A): Policies and procedures to establish, document, review and modify users’ access authorizations

iv. Standard: Security awareness and training program (all workforce, “including management”)

A. Specifications

I. Security reminders (A)

II. Protection from “malicious software” (A): Guarding against, detecting, reporting viruses, etc.

III. Log-in monitoring (A): Procedures for monitoring log-in attempts and reporting “discrepancies”

IV. Password management (A): Creation, changing and safeguarding

v. Standard: Contingency planning (emergency and “other occurrences” such as fire, vandalism, system failure, natural disaster) for information systems

A. Specifications

I. Data backup plan (R)

II. Disaster recovery plan (R)

IV. Emergency mode operation (R)

V. Plan testing and revision (A)

VI. Applications and data criticality analysis (A): “Assess relative criticality of specific applications and data”

vi. Standard: Evaluation

A. No separate specification; “technical and nontechnical evaluation,” periodic and “in response to environmental or operational changes,” of extent to which policies and procedures meet Security Rule requirements

vii. Standard: Business associates

A. Specifications (45 CFR § 164.314)

I. Contract or “other arrangement” required before covered entity “may permit a business associate to create, receive, maintain, or transmit electronic protected health information” on its behalf

a. Not required for transmissions to providers for treatment, by group health plan, HMO, health insurance issuer on behalf of group health plan to plan sponsor, or transmission to government agencies providing public benefits

B. Contract must include provisions (45 CFR 164.314(a) that:

I. Business associate will “implement administrative, physical and technical safeguards that reasonably and appropriately protect” electronic protected health information

II. Any business associate agent or subcontractor will also implement such safeguards

III. Business associate will report “any security incident of which it becomes aware”

IV. Contract may be terminated for breach of material term

b. 45 CFR §164.310: Physical safeguards

i. Standard: Facility access controls: Policies and procedures to limit physical access to information systems, while permitting authorized access

A. Specifications:

I. Contingency operations (A): Procedures for access to restore lost data under disaster recovery and emergency mode operations

II. Facility security plan (A): To safeguard facility and equipment against unauthorized access, tampering, theft

III. Access control and validation (A): Control and validate individuals’ access to facility and equipment, including visitor control and software testing/revision access control

IV. Maintenance records (A): Security-related facility elements (e.g. hardware, walls, doors, locks)

ii. Standard: Workstation use

A. No separate specification; policies and procedures to specify proper workstation functions, manner of performing functions, and physical attributes of workstation “surroundings”

iii. Standard: Workstation security

B. No separate specification; physical safeguards to restrict access to authorized users

iv. Standard: Device and media controls (hardware, electronic media)

A. Specifications:

I. Disposal (R)

II. Media Re-use (R)

III. Accountability (A): Records of “movement of hardware and electronic media and any person responsible therefore”

IV. Data backup and storage (A): “Create retrievable, exact copy of electronic protected health information, when needed, before movement of equipment”

c. 45 CFR §164.312: Technical safeguards

i. Standard: Access controls

A. Specifications:

I. Unique user identification (R): Unique name or number for identifying and tracking

II. Emergency access procedure (R): For obtaining access to electronic protected health information

III. Automatic log-off (A): Session termination after predetermined period of inactivity

IV. Encryption and decryption (A): Electronic protected health information in storage

ii. Standard: Audit controls

A. No separate specification; “hardware, software or procedural mechanisms that record and examine” system activity

iii. Standard: Integrity (protection against improper alteration or destruction)

A. Specification (A): Electronic mechanisms

iv. Standard: Person/entity authentication (confirmation of identity)

A. No separate specification; procedures to verify identity

v. Standard: Transmission security

A. Specifications:

I. Integrity controls (A): Ensure information is not improperly modified without detection

II. Encryption (A)

d. 45 CFR §164.316: Policies and procedures documentation

i Standard: Policies and procedures

A. No separate specification; may be changed at any time but changes must be documented

ii Standard: Documentation (policies and procedures; security actions, activities, assessment; in writing or electronic)

A. Specifications:

I. Time limit (R): Six years from later of creation or applicability

II. Availability (R): To individuals responsible for implementing documented procedures (presumably also to DHHS)

III. Updates (R): Periodic review, and in response to “environmental or operational changes”

3. Security regulations not included:

a. 45 CFR § 164.304: Definitions. Lack of inclusion confusing but not a problem – defined terms used in HITECH and Security Rule.

b. 45 CFR § 164.306: General rules – Security objectives, flexible approach, required vs. addressable specifications, maintenance. Lack of inclusion implies less discretion? Or nothing in particular?

c. 45 CFR § 164.314: Organizational requirements – Business associate contracts. Lack of inclusion confusing but meaningless? Is a business associate required to have a business associate contract with subcontractors or not?

F. HITECH Security Requirements Included

“This title” presumably means Title XIII – not just Subtitle D

1. Subtitle D requirements:

a. § 13401 – redundant, recursive

b. § 13401 – security breach notification

2. Other Title XIII security requirements - future standards adopted under § 3004?

G. BA Security Compliance Requirements

1. Implement security program meeting all the security regulation requirements

2. Also review CMS Sample Interview and Document Request for HIPAA Security Onsite Investigations and Compliance Reviews for supplemental perspective

3. Coordinate with CE(s) – some security measures may interfere with common or shared activities or systems

Examples: Transmission encryption, system access, authorization roles – there are others

Look for problems with differing risk tolerances

H. New BAC Privacy Rules

[A Business Associate may use and disclose PHI obtained pursuant to a BAC only] in compliance with each applicable requirement of [45 CFR § 164.504(e).] The additional requirements of this subtitle that relate to privacy and that are made applicable with respect to covered entities shall also be applicable to such a business associate and shall be incorporated into the business associate agreement between the business associate and the covered entity.

HITECH § 13404(a)

1. 45 CFR § 164.504(e): Privacy regulations BAC standard and specifications (see above)

2. Other privacy regulation compliance not required of BAs – except as provided in old BAC required provisions

3. BAC compliance now required of BAs by law

4. HITECH privacy requirements applied to BAs

a. “This subtitle” presumably means Subtitle D, not Title XIII

b. Subtitle D requirements applicable to CEs (see below) – health plan PHI disclosure restrictions, new minimum necessary provisions, new EHR accounting of disclosures rules, new patient access to information rules, new limitations on EHR sales and marketing

I. BAC Compliance

HITECH §§ 13401(a), 13404(a) provide that HITECH requirements “of this title” (security) and “of this subtitle” (privacy) “shall be incorporated into the business associate agreement between the business associate and the covered entity.”

Does “shall be incorporated” mean:

· “Are hereby incorporated by law” without further action required by the parties?

· That the parties “are hereby directed to incorporate the requirements into their BACs” by amendment or update?

No OCR guidance as of drafting date, so here are some suggestions for dealing with BACs:

· If OCR says amend, amend

· If OCR says amend right away, we have a lot of work to do fast

· If OCR says amend but enforcement will be stayed, we have a lot of work to do but hopefully more time to do it in

· If OCR says incorporated by law, amend anyway

1) Statutory provisions are hard to interpret as contract terms – especially HITECH

2) Statutory obligations do not define details of contract compliance

· E.g. security breach notification requirements do not specify CE notice terms, procedures for response coordination, cost allocations, etc.

· Staged amendment processes

1) Implement new forms to use going forward – new and renewing contracts

2) Ensure BACs are identified and subject to management

3) Communicate SOON with key BA or CE business partners

J. New BAC Termination Rules:

Section 164.504(e)(1)(ii) of title 45, Code of Federal Regulations, shall apply to a business associate . . . in the same manner that such section applies to a covered entity, with respect to compliance with the standards in sections 164.502(e) and 164.504(e) of such title, except that in applying such section 164.504(e)(1)(ii) each reference to the business associate, with respect to a contract, shall be treated as a reference to the covered entity involved in such contract.

HITECH § 13404(b)

· 45 CFR § 164.504(e)(1)(ii): Termination of business associate contract for breach

· 45 CFR § 164.502(e), .504(e): Business associate disclosure and contract standards and specifications

K. Old BAC Termination Rule

A covered entity is not in compliance with the standards in §164.502(e) and paragraph (e) of this section, if the covered entity knew of a pattern of activity or practice of the business associate that constituted a material breach or violation of the business associate's obligation under the contract or other arrangement, unless the covered entity took reasonable steps to cure the breach or end the violation, as applicable, and, if such steps were unsuccessful: (A) Terminated the contract or arrangement, if feasible; or (B) If termination is not feasible, reported the problem to [DHHS]

45 CFR § 164.504(e)(1)(ii)

L. Interpretation of the New Termination Rule

Here’s the old rule, with “Business Associate” substituted for “Covered Entity” and vice-versa, to demonstrate how this works.

A [Business Associate] is not in compliance with the standards in §164.502(e) and paragraph (e) of this section, if the [Business Associate] knew of a pattern of activity or practice of the [Covered Entity] that constituted a material breach or violation of the [Covered Entity’s] obligation under the contract or other arrangement, unless the [Business Associate] took reasonable steps to cure the breach or end the violation, as applicable, and, if such steps were unsuccessful: (A) Terminated the contract or arrangement, if feasible; or (B) If termination is not feasible, reported the problem to [DHHS]

45 CFR § 164.504(e)(1)(ii)

· How will this work in real life? How can a CE violate a BAC? (There are several ways I can think of)

· What BAs might learn about CE violations? Should CEs include some kind of BAs in compliance programs, e.g. violation hot lines?

· What traps exist? Can e.g. a BA law firm ethically report a CE violation?

· How to draft sensible BAC terms around this? Can the same kinds of terms be used for all contracts? Maybe include CE reporting and escalation requirements prior to DHHS notice or termination?

· Note risk of new, enhanced penalties for BAs for failure to notify or terminate

M. New Rules on HIPAA Criminal/Civil Penalties

Applicable to both CEs and BAs

In the case of a business associate that violates any provision of subsection (a) or (b), the provisions of sections 1176 and 1177 of the Social Security Act (42 U.S.C. 1320d–5, 1320d–6) shall apply to the business associate with respect to such violation in the same manner as such provisions apply to a person who violates a provision of part C of title XI of such Act.

HITECH § 13404(c)

· 42 USC § 1320d-6: HIPAA criminal penalties

· 42 USC § 1320d-5: HIPAA civil penalties

N. The Old Civil Penalties Rules

1. $100 per violation of Privacy or Security Rule requirement or prohibition

2. Maximum $25,000 per calendar year per “identical” requirement or prohibition

· Example: Unencrypted transmission = $100 penalty

· 250 unencrypted transmissions = $25,000 penalty

· 10,000 unencrypted transmissions = $25,000 penalty

3. “Continuing” violations (e.g. failure to conduct risk assessment) counted at one violation per day until cured

45 CFR §§ 164.404, .406

4. Affirmative defenses: Violation due to “reasonable cause,” not “willful neglect,” and under correction. 45 CFR § 160.410

5. Penalty aggravation/mitigation factors: Nature, harm caused by violation; intentional violation vs. violation “beyond control;” compliance history; financial factors. 45 CFR § 164.408

O. The New Civil Penalties Rules

· Violation not known (despite due diligence): Remains at $100/violation to $25,000 maximum

· Violation due to “reasonable cause:” Increased to $1,000/violation to $100,000 maximum

· Violation due to “willful neglect:” Increased to $500,000/violation to $1.5 million maximum

HITECH § 13410

· All penalties currently effective

· DHHS required to publish regulations on “willful neglect” and required to impose penalties for it beginning February 17, 2011

· State attorneys general granted civil penalties jurisdiction – and attorneys fees for successful action

· Affected individuals may be awarded penalty share per regulations to be effective beginning February 17, 2012

1. New penalty regime changes the BA calculus

a) Is the contract worth the risk?

b) Can the BA provide the same (or similar) services without PHI?

c) Some organizations clearly not – RHIOs, QIOs, etc.

d) Some organizations might be able to, for some services – consulting, accounting, law, etc.

e) Should the BA increase fees to meet increased regulatory burdens and risks?

P. Effective Dates and Potential for Extension Pending Regulations?

“Unless otherwise specified:” Feb. 17, 2010. HITECH § 13423.

· BA security regulation compliance: No.

· HITECH § 113401(c) requires annual “guidance,” compliance not contingent

· BAC compliance (if amendment required): Some elements; mostly not

· HITECH § 13404(a) requires incorporation of HITECH CE privacy requirements in BAC; some require regulations to be effective

Q. New Privacy Rules - PHI: Health Plan Disclosures

1. Existing Rule: 45 CFR § 164.522

(a)(1) Standard: right of an individual to request restriction of uses and disclosures.

(i) A covered entity must permit an individual to request that the covered entity restrict:

(A) Uses or disclosures of protected health information about the individual to carry out treatment, payment, or health care operations; and

(B) Disclosures permitted under § 164.510(b).

(ii) A covered entity is not required to agree to a restriction.

(iii) A covered entity that agrees to a restriction under paragraph (a)(1)(i) of this section may not use or disclose protected health information in violation of such restriction, except that, if the individual who requested the restriction is in need of emergency treatment and the restricted protected health information is needed to provide the emergency treatment, the covered entity may use the restricted protected health information, or may disclose such information to a health care provider, to provide such treatment to the individual§13405(a)

45 CFR § 164.522

2. New Mandatory Restriction:

REQUESTED RESTRICTIONS ON CERTAIN DISCLOSURES OF HEALTH INFORMATION.—In the case that an individual requests under paragraph (a)(1)(i)(A) of section 164.522 of title 45, Code of Federal Regulations, that a covered entity restrict the disclosure of the protected health information of the individual, notwithstanding paragraph (a)(1)(ii) of such section, the covered entity must comply with the requested restriction if—

(1) except as otherwise required by law, the disclosure is to a health plan for purposes of carrying out payment or health care operations (and is not for purposes of carrying out treatment); and

(2) the protected health information pertains solely to a health care item or service for which the health care provider involved has been paid out of pocket in full.

HITECH §13405(a)

3. Questions and Implications:

· What is “out of pocket?” Cash? Check? Credit card?

· Prudent approach: Accept cash. (Why not?) Consider whether to accept checks (stop payment risk), credit cards (dispute risk)

· How are indirect and referred providers notified? Do they have independent duties to restrict information from first provider (paid in full) even if they are not?

· Review policies, procedures processes and information system controls and modify as needed to implement restrictions

· What if information is needed for plan coverage decisions? Individual informed consent?

R. New Privacy Rules: Minimum Necessary

1. Existing Rules: 45 CFR § 164.502(b)

When using or disclosing protected health information or when requesting protected health information from another covered entity, a covered entity must make reasonable efforts to limit protected health information to the minimum necessary to accomplish the intended purpose of the use, disclosure, or request.

This requirement does not apply to:

(i) Disclosures to a health care provider for treatment;

(ii) Uses or disclosures made to the individual, as permitted under paragraph (a)(1)(i) of this section or as required by paragraph (a)(2)(i) of this section;

(iii) Uses or disclosures made pursuant to an authorization under § 164.508.

(iv) Disclosures made to the Secretary in accordance with subpart C of part 160 of this subchapter;

(v) Uses or disclosures that are required by law, as described by § 164.512(a); and

(vi) Uses or disclosures that are required for compliance with applicable requirements of this subchapter.

a. Applies to requests for PHI by Covered Entities, as well as their disclosures

· For recurring types of disclosures, implement policies identifying persons or classes of persons permitted to receive, and scope of information

· For all other types of disclosures, case-by-case determination using pre-established criteria

45 CFR § 164.514(d)

2. New Rule:

a. Two phase compliance:

· Statutory Compliance: February 17, 2009 – August 17, 2010+ (18+ months)

· Regulatory Compliance: Regulation effective date forward

b. Statutory period: The following provision applies:

A covered entity shall be treated as being in compliance with section 164.502(b)(1) . . . with respect to the use, disclosure, or request of protected health information only if the covered entity limits such protected health information, to the extent practicable, to the limited data set . . . or, if needed by such entity, to the minimum necessary to accomplish the intended purpose of such use, disclosure, or request, respectively.

Subject to same exceptions as apply under regulations

HITECH § 13405(b)

3. A limited data set is protected health information that excludes the following direct identifiers of the individual or of relatives, employers, or household members of the individual:

· Name address, phone, fax, email, SSN, other ID, vehicle/device ID, URL/IP address, biometrics, photos

· Limited data set may only be used for health care operations, research, public health reporting

45 CFR § 164.514(d)(2), (3)

BUT SEE:

Agreement required. A covered entity may use or disclose a limited data set under paragraph (e)(1) of this section only if the covered entity obtains satisfactory assurance, in the form of a data use agreement that meets the requirements of this section, that the limited data set recipient will only use or disclose the protected health information for limited purposes.

45 CFR § 164.514(d)(4)

4. Questions and Implications:

· Clearly applies to payment, health care operations, most other uses and disclosures

· What is the “practicable extent” for use of a limited data set?

· When do you “need” to use a broader data set?

· Probably for almost all payment, many health care operations

· Can a Covered Entity still rely on requestor representations about “necessary” scope?

· Need to review, probably revise minimum necessary policies

· What about limited data set agreements?

· How does all this integrate into business associate contracting?

S. Accounting of Disclosures

1. Existing Rule:

Individual entitled to accounting for disclosures made for six years prior to request, except for:

· Treatment, payment, health care operations;

· To the individual;

· Incidental to permitted uses and disclosures

· Pursuant to an authorization

· Directories, care support, certain notifications

· National security

· To correctional institutions or law enforcement

· As part of a limited data set

45 CFR § 164.528(a)

2. New Requirements:

a. Grandfathered, delayed compliance:

i. Current EHR users: January 1, 2014 (may be extended by rule to 2016)

ii. EHR acquired after January 1, 2009: Date of acquisition or January 1, 2011 (may be extended by rule to 2013)

3. New rules for EHR disclosures

(1) IN GENERAL.—In applying section 164.528 of title 45, Code of Federal Regulations, in the case that a covered entity uses or maintains an electronic health record with respect to protected health information—

(A) the exception under paragraph (a)(1)(i) of such section shall not apply to disclosures through an electronic health record made by such entity of such information; and

(B) an individual shall have a right to receive an accounting of disclosures described in such paragraph of such information made by such covered entity during only the three years prior to the date on which the accounting is requested.

HITECH § 13405(c)

4. New rules for BA disclosures

In response to an request from an individual for an accounting, a covered entity shall elect to provide either an—

(A) accounting, as specified under paragraph (1), for disclosures of protected health information that are made by such covered entity and by a business associate acting on behalf of the covered entity; or

(B) accounting, as specified under paragraph (1), for disclosures that are made by such covered entity and provide a list of all business associates acting on behalf of the covered entity, including contact information for such associates (such as mailing address, phone, and email address). A business associate included on a list under subparagraph (B) shall provide an accounting of disclosures (as required under paragraph (1) for a covered entity) made by the business associate upon a request made by an individual directly to the business associate for such an accounting.

HITECH § 13405(c)

3. Questions and Implications:

a. Treatment, payment, health care operations disclosures from EHRs will be added

· Can your existing EHR track them now? Will it be able to then? Will the EHR you are going to buy be able to do it?

b. Applies whenever external entities are given access

· Disclosure means the release, transfer, provision of access to, or divulging in any other manner of information outside the entity holding the information.

· Use means . . . the sharing, employment, application, utilization, examination, or analysis of such information within an entity that maintains such information.

· So what about e.g. independent ER contractor physicians using a hospital EHR in an OHCA?

c. If you disclose addresses only, will your BAs be able to respond? Will they want to?

T. Patient Access to PHI

1. Existing Rule: 45 CFR § 164.524

An individual has a right of access to inspect and obtain a copy of protected health information about the individual in a designated record set, for as long as the protected health information is maintained in the designated record set, except for:

· Psychotherapy notes;

· Information compiled in reasonable anticipation of, or for use in, a civil, criminal, or administrative action or proceeding;

· Certain information subject to Clinical Laboratory Improvement Act (CLIA), certain information about correctional inmates, certain research or Privacy Act-protected information, certain information received under confidentiality;

· Information a licensed professional has determined could cause harm to life or physical safety

2. New Rule:

In applying section 164.524 . . . in the case that a covered entity uses or maintains an electronic health record with respect to protected health information of an individual—

(1) the individual shall have a right to obtain from such covered entity a copy of such information in an electronic format and, if the individual chooses, to direct the covered entity to transmit such copy directly to an entity or person designated by the individual, provided that any such choice is clear, conspicuous, and specific; and

(2) notwithstanding paragraph (c)(4) of such section, any fee that the covered entity may impose for providing such individual with a copy of such information (or a summary or explanation of such information) if such copy (or summary or explanation) is in an electronic form shall not be greater than the entity’s labor costs in responding to the request for the copy (or summary or explanation).

HITECH § 13405(e)

3. Questions and Implications:

· How does the right to “direct the transmission” to a designated third party relate to authorization rights and requirements?

· Can you in fact quantify your costs of response?

U. Prohibition on EHR and PHI Sales

1. Existing Rule:

Sale or transfer as part of treatment, payment, healthcare operations not prohibited as long as other conditions met – remuneration not a factor

2. New Rules:

· Rule implementation: No longer than 18 months (August 17, 2010)

· Compliance: Six month from effective date (April 17, 2011)

· Effective date is publication of final rule + 2 months

A covered entity or business associate shall not directly or indirectly receive remuneration in exchange for any protected health information of an individual unless the covered entity obtained from the individual . . . a valid authorization that includes . . . a specification of whether the protected health information can be further exchanged for remuneration by the entity receiving protected health information of that individual.

HITECH § 13405(d)

Exceptions:

· Public health activities

· Research, as long as “price charged reflects the costs of preparation and transmittal of the data for such purpose”

· Treatment of the individual

· Sale, transfer, merger, consolidation of a covered entity, where the successor will be a covered entity

· Remuneration “by a covered entity to a business associate for activities involving the exchange of protected health information that the business associate undertakes on behalf of and at the specific request of the covered entity pursuant to a business associate agreement.”

· Providing an individual with a copy of PHI

3. Questions and Implications:

What is “remuneration?”

· Stark definition: “Remuneration means any payment, discount, forgiveness of debt or other benefits made directly or indirectly, overtly, in cash or in kind.”

What is “exchange” of PHI? May covered entity transfer temporary possession to 3rd party for use?

Can you quantify research-related costs?

V. Marketing

1. Existing Rule:

Use or disclosure of PHI for marketing purposes requires authorization and notice if “direct or indirect remuneration” is paid, excluding face-to-face communications and “nominal” gifts

45 CFR § 164.508(a)(3)

“Marketing” is a communication about a product or service that encourages recipients to purchase or use the product or service, or an arrangement between a covered entity and any other entity where the covered entity discloses protected health information to the other entity, in exchange for direct or indirect remuneration, for the other entity or its affiliate to make a communication about its own product or service that encourages recipients of the communication to purchase or use that product or service.

45 CFR § 164.501

Exceptions

Health-related product or service (or payment for such) provided by, or included in a plan of benefits of, the covered entity making the communication, including communications about entities in a health care provider or health plan network or added-value health-related products or services available only to a health plan enrollee.

Treatment of the individual; or

Case management or care coordination, or to direct or recommend alternative treatments, therapies, health care providers, or settings of care.

2. New Rule:

A communication by a covered entity or business associate that is about a product or service and that encourages recipients of the communication to purchase or use the product or service shall not be considered a health care operation . . . unless the communication is made as described in subparagraph (i), (ii), or (iii) of paragraph (1) of the definition of marketing in section 164.501 of such title.

HITECH § 13406(a)(1)

Exceptions:

A communication by a covered entity or business associate that is described in subparagraph (i), (ii), or (iii) of paragraph (1) of the definition of marketing . . . shall not be considered a health care operation . . . if the covered entity receives or has received direct or indirect payment in exchange for making such communication, except where—

Communication describes only a drug or biologic that is currently being prescribed for the recipient of the communication; and

Any payment received by such covered entity in exchange for making a communication described is reasonable; and either

The communication is made by the covered entity and the covered entity first obtains an authorization from the individual; or

The communication is made by a business associate on behalf of the covered entity and the communication is consistent with the written contract between such business associate and covered entity.

“Reasonable” to be determined by regulation

3. Questions and Implications:

· Read together with HITECH § 13405(d) (EHR and PHR sales)

· Note: Applies to communications on/after February 17, 2010

· Allows e.g. prescription refill reminders, not “switch” letters suggesting different drugs

· Will the rule on “reasonable” come out by February 17, 2010?

Caveat User: Data Mining and Sneaky Services Providers

According to Zero Hedge, Goldman Sachs may have been using data from activities on its news/research web portal, and possibly also its trading portal for Goldman clients, to "front run" its clients. "Front running" occurs when a brokerage firm (like Goldman) executes a trade on a stock its own behalf before executing a trade on behalf of a client for the same stock - which might, for example, result in a nice profit on a purchase for the front-runner if the following client trade is large (or otherwise influential) enough to move the stock price up, or avoid a nasty loss if the following client trade drives it down.

Front-running has been around for a while, and under some circumstances might be illegal insider trading, though that can be a hard case to make. The neat thing about Goldman's approach - and per Zero Hedge apparently that of some other comparable institutions' - is that they set up their terms of use so that users in fact consent to Goldman's use of data about their use of the web services for purposes implicitly including front running.

Terms of use, of course, are a form of contract users accept, by website actions ranging from explicit entry of user information and account setup, to simply continuing to access the website with notification of a link to the terms of use (all forms of electronic signature, generally legally binding by statute and caselaw). If you have notice of and an opportunity to read the terms of use and choose not to do so - the usual response; when did you last read a website's terms of use? - you're still bound by the information they contain and the agreements they include. (I haven't tried to find out how the Goldman website's terms of use are set up.)

The relevant provision in the Goldman terms of use states:

Monitoring by GS [Goldman Sachs]: Your use of the products and services on this Web site may be monitored by GS, and that the resultant information may be used by GS for its internal business purposes or in accordance with the rules of any applicable regulatory or self-regulatory organization.

If (1) front running is an "internal business purpose" of Goldman and (2) "in accordance with" implicitly includes the meaning "not prohibited by," website users have agreed that Goldman can use their website activity data to front-run them. If Goldman were to combine such data - which I assume could be pretty rich and detailed for a long-term user - with other information about the user, the user's employer, etc., etc., obtained from other sources - well, let's just say I think they would have a very valuable data set for their own trading decisions.

I assume some smart lawyers vetted all this for Goldman and concluded it wasn't prohibited by any applicable law - probably backed by some internal controls to avoid clear legal violations like actual insider trading by Goldman insiders who might have a fiduciary relationship to the client - but it seems to me unlikely that the average Goldman client using its website would anticipate this kind of use of its users' information, whether or not they read the terms of use. And I can readily imagine that front-running a client trade could harm the client's interests, if the broker trade ran prices up before a client purchase, or down before a client sale. But given the terms of use, they've accepted this use of their data.

I'm not sure this ends the legal inquiry; I haven't tried to figure out how the Gramm-Leach-Bliley privacy regulations or New York state privacy laws might be implicated. Again, I assume smart lawyers gave this an extensive - and expensive! - analysis, and there are internal controls intended to prevent clear violations. In any case where the user is acting on behalf of an institution these won't be implicated anyway, as they are intended to protect individual consumer privacy, not institutional interests. But I wouldn't be surprised to see NY AG Andrew Cuomo take an interest in what might have been going on under the hood, and perhaps the FTC as well. (Note: Rolling Stone reporter Matt Taibbi is on the case, so this may get some public traction.)

And one clear takeaway for me is that institutional clients of firms providing this kind of web service under this type of terms of use should seriously consider not using it. Unless the institution is using the service, and trading, on its own behalf, it probably owes some form of duty to its own clients (contractual, etc.) not to expose them to known, potentially harmful trading risks. Now that the risk of implicitly authorized front-running is known, seems to me it is something to avoid.

Caveat user. Read those terms of use!

Stop! Don't Sign that Business Associate Contract!

As readers of this blog (should) know, the HITECH provisions of the stimulus bill include a very significant expansion of regulatory authority over business associates. They also include a very significant increase in penalties for HIPAA violations. The upshot of these changes is that many organizations which were not previously subject to HIPAA penalties will (relatively) soon be exposed to new, important liability risks. This changes the risk calculus for many organizations and individuals which may want to reconsider whether they are, or want to be, business associates.

Previoiusly, for many organizations and individuals in many business relationships with Covered Entities there has been little or no downside to signing a business associate contract. In many cases - I've dealt with a great many of them - Covered Entity staff handling contracts for IT, accounting, legal and various kinds of consulting services, have simply assumed that a Business Associate Contract is necessary. This assumption may or may not have been true, but was put forward without analysis, based upon a misunderstanding of the law, out of an excess of caution, or "because our lawyer requires it." (Of course, lawyers themselves have been guilty of pushing this kind of assumption.)

For the purported Business Associate in this situation the Business Associate Contract has therefore been an obstacle to the deal, but generally a minor one. The Business Associate would not be exposed to regulatory penalties for violation of the contract, and where the Business Associate Contract's terms don't include significant penalties for violation - often the case, especially when the Covered Entity has gone with a simple form - the Business Associate's risk for violation is pretty much limited to termination of the contract. As legal risks go, this isn't a big one. So, many organizations have been willing to sign off on Business Associate Contracts as a condition to closing a deal or relationship with a Covered Entity, even if they really aren't acting as a Business Associate, or could provide appropriate services without doing. so. I know of quite a few IT, legal, accounting and consulting services companies where this is the case.

If you're in that position you probably want to rethink it. As of next February 17, Business Associates will be directly regulated by Health and Human Services, directly subject to audit, and directly exposed to penalties for Security Rule violations, violations of HITECH provisions, and violations of their Business Associate Contracts. And these penalties will be potentially much greater - are a lot bigger than they used to be; think hundreds of thousands or even millions of dollars, if you violate enough provisions and do it with "willful neglect."

Now, just signing a Business Associate Contract shouldn't be enough to make you a Business Associate - though it could certainly be taken as evidence you and your trading partner intend for you to be. I would take the position that even if my client signed a document accepting Business Associate status, it really isn't unless it's done something involving Protected Health Information on behalf of a Covered Entity. But that's a legal argument, and if I have to make it my client will already be under investigation and at risk of penalties. I'd prefer not to go there, myself.

So, if you're a Business Associate, or think you might be, or never really thought about it but signed off on a contract to make a deal happen, you probably want to consider the services you provide, whether you can or want to provide them in a different way if they currently involve Protected Health Information, and maybe whether the existing compensation reflects your soon-to-increase risk.

Me? As a lawyer and sometimes Business Associate, I certainly will be looking at this.

Caselaw: When Bad Security Makes for Invalid Electronic Signatures

Signatures are essential - as in, legally required - for many healthcare records, among them medical records, drug orders and prescriptions. Failure to sign violates licensing and frequently other state law provisions, and in some cases federal requirements and accreditation standards.Federal and state laws - E-SIGN and the Uniform Electronic Transactions Act (UETA, adopted in almost all states) also permit electronic signatures, and these have become a standard part of electronic health record (EHR) and electronic prescribing (e-Rx) systems.

Neither E-SIGN nor UETA specify the technologies which are acceptable as electronic signatures, but instead leave it up to the agreement of the parties. As a matter of law, then, an electrronic signature is any "electronic sound, symbol, or process attached to or logically associated with a record and executed or adopted by a person with the intent to sign the record." For example, when you download a new application you are usually confronted with several pages of license agreement and a "click to accept" button, or something similar. When you click the button, you are executing an electronic process (the results of the click) logically associated with a record (the license agreement) with intent to sign (implied by the fact that you clicked after being asked if you accept the license agreement). From a legal point of view, you have just electronically signed the license agreement.

As you can imagine, this open standard creates many opportunities for error and fraud. You could click to accept without intending to, just because you're fumble-fingered. (This is why double-click is often better solution.) Somebody else could log on to your account, or create an account using your information, and "sign" records in your name - for example, bank transfer authorizations. And so on.

The security of the process used to create an electronic signature is therefore essential to its reliability, and both E-SIGN and UETA have provisions allowing an electronic signature's validity to be proven by evidence of the "efficacy" of the security of the process. Conversely, "bad" security may be grounds to contest an electronic signature, and even have it thrown out.

This recently happened in a Kansas federal district court case, Kerr v. Dillard Store Services. The record there was an arbitration agreement potentially applicable to the plaintiff's discrimination claim against her employer.In Kerr, the employer required employees "to memorialize their arbitration agreements by executing electronic arbitration agreements
through an intranet computer system." The signature process was as follows:

To access the intranet each associate had a unique, confidential password that was created by and known only to the associate. Executing the agreement to arbitrate required the associate to (1) enter his or her social security number or associate identification number (AIN); (2) enter his or her secure password and; (3) click the “accept” option at the bottom of the arbitration agreement screen.

The execution transaction was confirmed by an email to the employee. All in all, a pretty standard electronic signature process, better than many, in my experience.

Dillard, the employer, tried to hold employee Kerr to the online arbitration agreement it claimed she had signed. However, the plaintiff claimed she never executed this process, and the burden of proof was on the employer. The court found for Kerr, reasoning that:

The problem with Dillard’s position is that it did not have adequate procedures to maintain the security of intranet passwords, to restrict authorized access to the screen which permitted electronic execution of the arbitration agreement, to determine whether electronic signatures were genuine or to determine who opened individual emails. . . . Therefore, it is not inconceivable Champlin [the store secretary] or a supervisor logged on to plaintiff’s account and executed the agreement. . . . Dillard’s has not demonstrated the efficacy of its security procedures with regard to electronic signature. . . . On this record, the Court cannot find that it is more likely than not true that plaintiff executed the electronic agreement to arbitrate.

While Kerr is not legally binding authority, as an unpublished district court decision, it does demonstrate the pitfalls of bad security for electronic signature processes as well. Healthcare organizations, which depend on signed records for essential functions associated with some of their most significant liabilities, might do well to consider how their solutions would look in court.

Red Flag Rule Board Consent and Policy

If you've surfed this site, you know that one of my tenets is that we're all generally better off sharing key policies - it improves our overall knowledge base and helps set a standard of care.

In that spirit, here are some materials you might consider if your healthcare organization needs to come into compliance with the Federal Trade Commission's Red Flag Rules - which are, by the way, effective May 1, 2009. Of course, documents like these should only be adopted as part of a good data protection program, which all healthcare ogranizations should already have for HIPAA compliance purposes. I'd also strongly suggest having a look at the open source Security Incident Response Policy I posted here in 2007 - it goes well with these.

If you don't know what this is all about, a good place to start is with the FTC's own web site. And as ever, this is educational material, not legal advice. If you think you need to adopt something like this, ask your lawyer! And feel free to share these with him or her.
__________________________________________________________________________________________________________________________________________________________________________

Copyright 2009 © John R. Christiansen/Christiansen IT Law
Creative Commons Attribution 3.0 License
Distribution Permitted with Attribution Retained

CONSENT RESOLUTION FOR ADOPTION OF IDENTITY THEFT PREVENTION PROGRAM FOR [HEALTHCARE PROVIDER NAME]

The undersigned, being all of the Board of [Directors/Trustees] of [Healthcare Organization/Business Associate], a ___________ [ENTITY TYPE] (the "[ENTITY"), hereby adopt and consent to the adoption of the following resolutions:

A. The Board has been advised by ENTITY’s [General Counsel/Legal Department/Law Firm], its legal counsel, with respect to the Federal Trade Commission’s Identity Theft Prevention Red Flag Rules, as codified at 16 CFR 681.2 (“Red Flag Rules”).

B. The Board has been further advised by [General Counsel/Legal Department/Law Firm] that [s/he/it] has determined, upon consultation with ENTITY’s [Chief Financial Officer/Chief Information Officer/Compliance Officer/Billing Department Head/Medical Records Department Head/Consultant/other relevant parties], that ENTITY is a “Creditor” and maintains “Covered Accounts” within the meaning of the Red Flag Rules. [General Counsel/Legal Department/Law Firm] has therefore determined that ENTITY is required to comply with the Red Flag Rules.

C. The Board has been further advised by ENTITY’s [Chief Information Security Officer/Compliance Officer/Security Consultant] that [s/he] has conducted an assessment of identity theft risks associated with ENTITY’s Covered Accounts, and determined that there are vulnerabilities which may present potential financial, operational, compliance, reputational or litigation risks to ENTITY, as well as financial, reputational or patient safety risks to ENTITY’s patients.

D. In order to comply with the Red Flag Rules and address identity theft risks, [General Counsel/Legal Department/Law Firm] and [Chief Information Security Officer/Compliance Officer/Security Consultant] have recommended to the Board that ENTITY adopt an Identity Theft Prevention Program. The [Chief Information Security Officer/Compliance Officer/Security Consultant] has further recommended that the Identity Theft Prevention Program be integrated with ENTITY’s existing [Information Security/Compliance] Program, due to the close relationship between identity theft and prevention and the information protection and compliance goals of the latter program, and in order to implement the Identity Theft Prevention Program more efficiently.

Based upon these findings and recommendations, the Board has resolved as follows:

RESOLVED, that [Chief Information Security Officer/Compliance Officer/Security Consultant], in consultation with [General Counsel/Legal Department/Law Firm] and [Chief Financial Officer/Chief Information Officer/Compliance Officer/Billing Department Head/Medical Records Department Head/Consultant/other relevant parties], is authorized and directed to develop and implement an Identity Theft Prevention Program, as part of ENTITY’s [Information Security/Compliance] Program.

RESOLVED, that [Chief Information Security Officer/Compliance Officer/Security Consultant] and [General Counsel/Legal Department/Law Firm] shall be responsible for updating and revision of the Identity Theft Prevention Program to address changes in applicable law, changes in ENTITY’s operations or systems affecting identity theft risks, identity theft or security incidents indicating new or previously unidentified risks, and other factors affecting the effectiveness of the Identity Theft Prevention Program, in consultation with the [Chief Financial Officer/Chief Information Officer/Compliance Officer/Billing Department Head/Medical Records Department Head/Consultant/other relevant parties], as appropriate.

RESOLVED, that the [Chief Information Security Officer/Compliance Officer/Security Consultant] and [General Counsel/Legal Department/Law Firm] shall report to the Board when the Identity Theft Prevention Program has been implemented, at the next regular meeting of the Board after the effective date of such implementation, and in any case at the next regular meeting of the Board after [TIME PERIOD]. Following implementation, the [Chief Information Security Officer/Compliance Officer/Security Consultant] shall include a report on the Identity Theft Prevention Program along with [his/her] regular reports to the Board on the [Information Security/Compliance] Program.

RESOLVED, that the Board hereby authorizes the [Chief Information Security Officer/Compliance Officer/Security Consultant] to spend up to ______________ dollars for development and implementation of the Identity Theft Prevention Program. Following implementation, the Identity Theft Prevention Program shall be included as an element of the annual [Information Security/Compliance] Program budget, according to ENTITY’s usual procedures.
_____________________________________________________________________________________

Copyright 2009 © John R. Christiansen/Christiansen IT Law
Creative Commons Attribution 3.0 License
Distribution Permitted with Attribution Retained

ENTITY NAME Identity Theft Prevention Policy

Information Security Policy No. 5.4

Objective of this Policy: The objective of this Policy is to provide assurance that neither ENTITY’s patients nor ENTITY are harmed by ENTITY’s receipt, creation, use, processing or disclosure of false or inaccurate personal information, including but not limited to protected health information as defined by Health Insurance Portability and Accountability Act of 1996 and its implementing regulations ("HIPAA").

This Policy is intended to help accomplish these objectives by providing guidance to ENTITY’s Workforce and Contractors, so that they will be able to:

• Recognize events or circumstances which may indicate that that identity theft is occurring or has occurred;

• Know how to report possible identity theft;

• Know who is responsible for and authorized to respond to possible identity theft; and

• Know the procedures which should be followed in responding to possible identity theft.

Recognizing Identity Theft: All members of ENTITY’s Workforce and Contractors are responsible for knowing how to identify possible identity theft affecting an ENTITY patient.

Identity theft is the inappropriate or unauthorized misrepresentation of personal information for the purpose of obtaining access to property or services. Identity theft is often committed in order to obtain credit to purchase consumer goods, but may also be committed to obtain medical care, drugs and supplies, or payment for care, services or supplies. Identity theft may result in false or inaccurate information becoming included in medical and billing records, and other patient records, and provided to third parties who may rely upon it in making diagnostic, treatment, credit and other important decisions.

The following are examples of facts and circumstances which may indicate identity theft. These are only examples, and many other facts or circumstances may be identity theft indicators.

• Identification documents which appear to have been altered or forged.

• The patient cannot provide documentation of identifying information, such as a health insurance card.

• The patient provides inconsistent identifying information, such as a Social Security Number in a range which does not correlate with the reported birth date.

• The Social Security Number or other identification or account number provided is already identified with another patient.

• The patient’s medical history, physical appearance or diagnosis is inconsistent with the same information in the medical records.

• A report by the patient or insurance company that coverage for the provision of legitimate products or services has been denied because insurance benefits have been depleted or a lifetime cap has been reached, which is inconsistent with known coverage.

• A patient inquires or complains about inappropriate billing or notices, such as:

• A bill for another individual, for services the patient denies receiving, or from a health care provider the patient denies receiving services from.

• An explanation of benefits or other insurance notification for products or services the patient denies receiving.

• A collection notice or credit report for a debt for products or services the patient denies receiving, or from a health care provider the patient denies receiving services from.

• The repeated return of mail sent to the patient’s address of record as undeliverable, while products or services continue to be provided to the patient.

• Notification by the patient, an individual claiming to be a victim of identity theft, any law enforcement agency, or any other person that an account or record has been opened or created fraudulently by ENTITY.

• The receipt of identification information associated with known fraudulent activity.

Reporting and Responding to Potential Identity Theft: All members of the Workforce and Contractors are required to report possible or suspected identity theft when they obtain information or observe activities or records which reasonably seem to indicate its occurrence.The [Chief Information Security Officer/Compliance Officer/Security Consultant] shall provide forms for such reports. Reports may also be made to the [COMPLIANCE HOTLINE].

Each [BUSINESS UNIT] shall establish written procedures for reporting and initial investigation of potential identity theft, including identification of accountable investigative staff, expected investigative activities, and expected initial investigation response times. The results of each initial investigation shall be documented in writing. Reports and investigation results documentation shall be retained by the [BUSINESS UNIT] for one year. The [Legal Department/Chief Information Security Officer/Compliance Officer] shall review such documentation annually for internal reporting purposes.

In the event an initial investigation determines that there is a reasonable possibility of identity theft, the [BUSINESS UNIT HEAD] shall promptly report that finding to the [Legal Department/Chief Information Security Officer/Compliance Officer]. The [Legal Department/>Chief Information Security Officer/Compliance Officer] shall document any such report and promptly initiate further investigative action. The results of any such investigation shall be documented in writing and retained by [Legal Department/>Chief Information Security Officer/Compliance Officer]for at least one year, and such reports shall be reviewed annually for internal reporting purposes.

Any identity theft confirmed by the Legal Department/Chief Information Security Officer/Compliance Officer] shall be treated as a Security Incident, subject to the Security Incident Response Policy.
WHERE ANY INDIVIDUAL HAS REASON TO BELIEVE THAT POSSIBLE IDENTITY THEFT ACTIVITY HAS RESULTED IN THE RECEIPT, CREATION OR DISCLOSURE OF FALSE OR INACCURATE INFORMATION WHICH MAY BE USED IN CARE OR TREATMENT DECISIONS POTENTIALLY AFFECTING PATIENT HEALTH OR SAFETY, THE POTENTIAL IDENTITY THEFT SHALL BE REPORTED IMMEDIATELY TO THE [APPROPRIATE OFFICER].

I'm now blogging at HITRUST Central

You probably noticed I haven't been keeping this blog up very well. Fact is, I was hoping for some more conversation! So, I've decided to join the blogging at HITRUST Central, a community website maintained by the Health Information Trust Alliance - click the link and look for my blog, if you want.

I will likely post every now and again here, on topics not appropriate for HITRUST Central.

Thanks!

How Do You Amend Your Terms of Use? Hint: Don't Hide the Ball.

I've just caught up to a 9th Circuit case on the adequacy of notification of changes to website terms of use, for purposes of binding users. I'm a bit embarrassed as it's a few months old, but in my defense the holding is rather buried and its implications probably weren't clear to the folks doing the indexing.

The case, *Douglas v. U.S. District Court*, 495 F.3d 1062 (9th Cir. 2007), involved a change to terms of use for an AOL subsidiary providing long-distance telephone services. The subsidiary was acquired by Talk America, which changed the existing terms of use to add a number of new clauses, including a new arbitration provision and a waiver of the right to class actions. The plaintiff, a California resident, filed a class action on a number of claims arising from the change in terms. The defendant moved to compel arbitration based on the new arbitration provision. The District Court granted arbitration and the plaintiff appealed.

On appeal the 9th Circuit held the arbitration clause was not enforceable, as a matter of:

(1) General contract law, because Talk American did not provide adequate notice of the changes to the plaintiff: "Nor would a party know when to check the website for possible changes to the contract terms without being notified that the contract has been changed and how. Douglas would have had to check the contract every day for possible changes. Without notice, an examination would be fairly cumbersome, as Douglas would have had to compare every word of the posted contract with his existing contract in order to detect whether it had changed."

(2) California law, under which "a contract can be procedurally unconscionable [i.e., unenforceable] if service provider has overwhelming bargaining power and presents a "take-it-or-leave-it" contract to a customer — even if the customer has a meaningful choice as to service providers."

I won't say that this is necessarily a dramatic change to existing law, because "existing law" in this area hasn't exactly been clear. The case doesn't analyze existing caselaw on "clickwrap" or "shrinkwrap" agreements, although this is clearly what it deals with. It doesn't discuss the possible distinctions between consumer transactions, which apparently were at stake here, and B2B or other sophisticated party transactions.

What I would say is that this is a caution-and-warning for management of terms of use, privacy notices, website licensing and the like: If you don't push out amendments, they may not be binding in court. Have a look at how you manage these changes. (What, you don't already?)

I would also say that this indicates the importance of jurisdictional issues: Don't assume there are "general principles" which apply to your online agreements (whether you call them terms of use, privacy notices, licenses or whatever); assume rather that the laws of the most Draconian jurisdiction where you do business apply. (Again, you don't")

And finally, beware of court opinions coming out of left field. This was an important decision, which evidently hadn't been adequately briefed on electronic commerce issues, and bubbled up out of arbitration caselaw. Those who like sausages, perhaps, shouldn't watch the laws being made . . .

And my guess is that due to the *apparently* narrow nature of the holding (re arbitration) this isn't a candidate for S.Ct. review.