Directs federal agencies participating to:

• Transmit to Congress a cybersecurity strategic research and development plan and triennial updates; and
• Develop and annually update an implementation roadmap for such plan. Provides for the award of computer and network security research grants by the National Science Foundation (NSF) in the research areas of social and behavioral factors, including human-computer interactions, and identity management.

Instructs that applications for the establishment of Computer and Network Security Research Centers include how such Centers will partner with government laboratories, for-profit entities, other institutions of higher education, or nonprofit research institutions.

Requires the NSF Director to carry out a program of awarding fellowships to encourage young scientists and engineers to conduct postdoctoral research in the fields of cybersecurity and information assurance, including the research areas under which computer and network security research grants are awarded.

Requires the Office of Science and Technology Policy (OSTP) Director to convene a cybersecurity university-industry task force to explore mechanisms for carrying out collaborative R&D activities. Requires (currently, permits) the National Institute of Standards and Technology (NIST) Director to establish priorities for the development of checklists of settings and options that minimize security risks associated with computer systems that are, or are likely to become, widely used within the federal government.

Requires:

• Development or identification and revision or adaptation as necessary, of checklists, configuration profiles, and deployment recommendations for products and protocols that minimize such risks; and
• Development of automated security specifications respecting checklist content and associated security related data.  Ensures that any products developed under the National Checklist Program for any information systems, including the Security Content Automation Protocol, be disseminated to federal agencies Requires conducting of intramural security research activities under NIST’s computing standards program.

Instructs the NIST Director to:

• Ensure coordination of U.S. government representation in the international development of technical standards related to cybersecurity;
• Implement a cybersecurity awareness and education program through the Manufacturing Extension Partnership program; and
• Establish a program to support development of technical standards, metrology, testbeds, and conformance criteria with regard to identity management research and development.

(Summary excerpted from http://www.govtrack.us/congress/bill.xpd?bill=h111-4061).

Would you like to play a nice game of chess? originally appeared on Law Blog 2.0 on February 5, 2010.

          

EHR Standards

The National Institute of Standards and Technology awarded Booz Allen Hamilton Inc. a contract to develop a testing method and processes for certifying electronic health record systems on January 13th.  Omitted from the announcement and underlying justification for a non-competitively awarded contract is that CCHIT already has an existing framework for testing EHR systems.  The $400,000 contract, announced on January 13, will result in a testing framework for health IT, a certification “process document” and other planning tools.  This probably means that we will not see such certification standards until at least April 2010 or later.  It is not clear how said standards and testing framework can be effectively deployed at a national level and implemented by EHR vendors and hospital systems by 2011.  Given the urgent timeline it is time to for direct coordination of efforts between NIST and CCHIT to push out a workable plan for certification of EHR systems.

Based on NIST’s website NIST is on the cutting edge of developing health related standards and certification criteria.  (See http://xw2k.nist.gov/healthcare/ehr.htm)  As early as August 13, 2002 NIST produced a concept paper highlighting key issues for developing and then certifying against EHR standards. (See http://www.itl.nist.gov/div897/ctg/it_healthcare/conceptpaper.pdf)  Additionally NIST has “provided comments and assistance to EHR certification efforts such as the Certification Commission for Healthcare Information Technology (CCHIT).” (See http://xw2k.nist.gov/healthcare/ehr.htm)  In 2001 NIST prepared a whitepaper on conformance testing for EHR systems. (See http://www.itl.nist.gov/div897/ctg/conformance/ebxml-test-framework.pdf).

Based on NIST own whitepapers I cannot help but wonder why there has not been further movement on the development of certification criteria, or at least recognition that action to develop certification criteria should have begun last summer not January of 2010.  The implementation of Health Information Technology is a corner stone to ARRA, but significant details remain unknown potentially discouraging the adopting of EHR systems.

Mark Leavitt , MD, PHD, in a recent article entitled: “Reading the Tea Leaves in a Disclosure Document: When will ONC and NIST be prepared to accredit health IT certifying bodies?” (see http://ehrdecisions.com/2010/01/15/reading-the-tea-leaves-in-a-disclosure-document-when-will-onc-and-nist-be-prepared-to-accredit-health-it-certifying-bodies/) made some interesting observations:

First, he sees nothing to suggest that ONC, NIST, or Booz Allen intend to build and operate a certification program themselves.  They do need to develop a well-defined set of policies and processes for accreditation of those programs;

Second, Dr. Leavitt observes that “this particular contract, described as a bridge to an upcoming acquisition (i.e. contract) runs 3 months, with a 3 month optional extension. Sounds to us like the soonest the accreditation package would be ready is July 2010.”

Per the Federal Budget Office announcement — “This procurement is a logical follow-on task order to NIST Task Order No. SB134107NC0535. The original task order was competed and then awarded as a General Services Administration (GSA) Federal Supply Services (FSS), action under Booz Allen Hamilton’s Mission Oriented Business Integrated Services (MOBIS), Contract No. GS23F9755H.”

Details on NIST Task Order No. SB134107NC0535 are available at the following website, http://www.dgmarket.com/tenders/np-notice.do~1983433#, at least based on the subject matter listed on the website it is unclear how NIST Task Order No. SB134107NC0535 has anything to do with SB1341-10-RQ-0072. The earlier contract was awarded in 2007, provides for Mission Oriented Business Integrated Services (MOBIS).  Attached hereto is a copy of what appears to be the original contract. (https://www.gsaadvantage.gov/ref_text/GS23F9755H/0FDO32.1S4MFB_GS-23F-9755H_GS23F9755H.PDF)

Booz Allen Hamilton, Inc Receives Non-Competitively Awarded Contract to Develop Certification and Accreditation Program for testing EHR Systems originally appeared on Law Blog 2.0 on January 18, 2010.

          

HHS

On December 1st, 2009 the Office of the Secretary of the Office of the National Coordinator (ONC) for Health Information Technology announced the creation of a new Chief Privacy Office and the Office of Economic Modeling and Analysis (among three others including the Office of Chief Scientist, Deputy National Coordinator for Programs & Policy, and Deputy National Coordinator for Operations).  The New Chief Privacy Officer is a necessary creation under the ARRA (and the HITECH Act).  This role is different from the other positions that seem to be a re-organization of roles and responsibilities that already existed to some extent just with more specificity around functions and duties.  Aside from the Chief Privacy Officer the New Economic Modeling and Analysis Position seems like a timely creation given recent articles discussing whether Health Information Technology and more specifically Electronic Health Record Systems (EHRs) actually reduce the cost of care and/or increase the quality of care.  Also of note, the new Office of the Deputy National Coordinator for Programs and Policy will be responsible for the open source Connect initiative and the National Health Information Network.

 (see http://healthit.hhs.gov/portal/server.ptopen=512&objID=1200&&PageID=15520&mode=2&in_hi_userid=10741&cached=true)

Below is a diagram detailing the new offices relative to the National Coordinator.

The Notice in the Federal Register note that the reorganization affects all four of the original Director-level offices:

• The Office of Health Information Technology Adoption (OHITA);
• The  Office of Interoperability and Standards (OIS);
• Office of Programs and  Coordination (OPC); and
• The Office of Policy and Research (OPR).

Five offices will have direct reporting capability to the National Coordinator for Health Information Technology (National Coordinator):

1. The Office of Economic Modeling and  Analysis (ARB);
2. the Office of the Chief Scientist (ARC);
3. The Office of the Deputy National Coordinator for Programs & Policy (ARD);
4. The Office of the Deputy National Coordinator for Operations (ARE); and
5. The Office of the Chief Privacy Officer (ARF).

(see http://edocket.access.gpo.gov/2009/E9-28755.htm).

The Office of the Chief Privacy Officer will advise the National Coordinator.  Chief Privacy Officer of the Office of the National Coordinator for Health Information Technology will be appointed by the Secretary.  The Office of the Chief Privacy Officer duties include:

1. Advising the National Coordinator on privacy, security, and data stewardship of electronic health information; and
2. Coordinating the Office of the National Coordinator for Health Information Technology’s efforts with similar privacy officers in other Federal agencies, State and regional agencies, and foreign countries with regard to the privacy, security, and data stewardship of electronic, individually identifiable health information.

The Office of Economic Modeling and Analysis responsibilities include:

1. Applying advanced mathematical or quantitative modeling to the U.S. health care system for simulating the microeconomic and macroeconomic effects of investing in health information technology; and
2. Providing advanced policy analysis of health information technology strategies and policies to the National Coordinator.

The purpose this position will be to model varying public policy scenarios to perform advanced health care policy analysis for requirements of the Recovery Act, such as reductions in health care costs resulting from adoption and use of health information technology.  The results of these analyses provided to the National Coordinator will inform strategies to enhance the use of health information technology in improving the quality and efficiency of health care and improving public health.

The Office of the Chief Scientist will be responsible for:

1. Applying research methodologies to perform evaluation studies of health information technology grant programs;
2. Identifying, tracking and supporting innovations in health information technology;
3. Leading research activities mandated under the HITECH Act provisions of ARRA;
4. Promoting applications of health information technology that support basic and clinical research;
5. Collecting and communicating knowledge of health care informatics from and to international audiences;
6. Collaborating with other agencies and departments on assessments of new health information technology programs; and
7. Developing and maintaining educational programs for staff of the Office of the National Coordinator and advising the National Coordinator concerning the educational needs of the field of HIT.

The Office of the Chief Scientist possesses and utilizes specialized knowledge of medical bioinformatics, which involves the study and application of advanced information methods and technologies in support of health care and population health.

The Office of the Deputy National Coordinator for Programs and Policy assumes functions previously performed by the Office of Health Information Technology Adoption, the Office of Interoperability and Standards, the Office of Adoption Provider Support, the Office of State and Community Programs, and the Office of Policy and Planning.  The new office will lead ONC programs related to health information exchange, regional extension centers, training of the health IT workforce, and the development of technical standards for interoperability, security, and certification of health IT systems.  The new office comprises:

1. The Office of Standards and Interoperability, with responsibility for standards, security, certification, the Nationwide Health Information Network, Federal Health Architecture and the CONNECT program;
2. The Office of Provider Adoption Support, which administers the Regional Extension Centers program and health IT workforce development;
3. The Office of State and Community Programs, which administers the state-level health information exchange program and the Beacon Communities Program; and
4. The Office of Policy and Planning, which is realigned to include all policy development, including privacy and security policy, and is liaison with legal affairs and legislative affairs, regulations development  and externally focused strategic planning.

The Office of the Deputy National Coordinator for Operations is responsible for activities that are vital to supporting ONC’s numerous programs and enhancing ONC’s ability to communication about health IT.

Office of the National Coordinator — Time to Reorganize. originally appeared on Law Blog 2.0 on December 10, 2009.

          

Recent HHS Guidance has emphasized key areas of importance related to a covered entity’s security assessment-

This guidance document has been prepared with the main objective of reinforcing some of the ways a covered entity may protect EPHI when it is accessed or used outside of the organization’s physical purview. In so doing, this document sets forth strategies that may be reasonable and appropriate for organizations that conduct some of their business activities through (1) the use of portable media/devices (such as USB flash drives) that store EPHI and (2) offsite access or transport of EPHI via laptops, personal digital assistants (PDAs), home computers or other non corporate equipment.

The Centers for Medicare & Medicaid Services (CMS) has delegated authority to enforce the HIPAA Security Standards, and may rely upon this guidance document in determining whether or not the actions of a covered entity are reasonable and appropriate for safeguarding the confidentiality, integrity and availability of EPHI, and it may be given deference in any administrative hearing pursuant to 45 C.F.R. § 160.508(c)(1), the HIPAA Enforcement Rule.

The kinds of devices and tools about which there is growing concern because of their vulnerability, include the following examples: laptops; home-based personal computers; PDAs and Smart Phones; hotel, library or other public workstations and Wireless Access Points (WAPs); USB Flash Drives and Memory Cards; floppy disks; CDs; DVDs; backup media; Email; Smart cards; and Remote Access Devices (including security hardware).

In general, covered entities should be extremely cautious about allowing the offsite use of, or access to, EPHI. There may be situations that warrant such offsite use or access, e.g., when it is clearly determined necessary through the entity’s business case(s), and then only where great rigor has been taken to ensure that policies, procedures and workforce training have been effectively deployed, and access is provided consistent with the applicable requirements of the HIPAA Privacy Rule.

(see http://www.cms.hhs.gov/SecurityStandard/Downloads/SecurityGuidanceforRemoteUseFinal122806rev.pdf).

Special publication 800-53, Revision 3 includes: (1) a simplified, six-step Risk Management Framework; (2) additional security controls and enhancements for advanced cyber threats; (3) recommendations for prioritizing security controls during implementation or deployment; (4) revised security control structure with a new references section; (5) guidance on using the Risk Management Framework for legacy information systems and for external information system services providers; (6) Updates to security control baselines based on current threat information and cyber attacks; (7) Organization-level security controls for managing information security programs; and (8) Guidance on the management of common controls within organizations.  Table 1 below maps HIPAA Security implementation specifications to NIST Security controls.  The NIST taxonomy of controls, as mapped by NIST SP 800-66, is invaluable in understanding the technical details of how to implement HIPAA compliant safeguards and what additional safeguards should be evaluated.

NIST Assessment Methodology

Encryption of portable media is a key enforcement priority of the OIG.  USB flash drives and other portable media are usually put in bags, backpacks, laptop cases, jackets, trouser pockets or are left at unattended workstations.  Tracking corporate data stored on personal flash drives is a significant challenge; the drives are small, common, and constantly moving.  Consequently USB drives are frequently misplaced.  Most HIPAA covered entities and business associates have strict management policies toward USB drives, and some companies ban them to minimize risk (by prohibiting the drives in a company acceptable use policy and/or in the operating system configuration).

Table 1 – Data by Type Copied by Employees

Other findings include:

1. 53 percent of respondents downloaded information onto a CD or DVD, 42 percent onto a USB drive and 38 percent sent attachments to a personal e-mail account;
2. 79 percent of respondents took data without an employer’s permission;
3. 82 percent of respondents said their employers did not perform an audit or review of paper or electronic documents before the respondent left his/her job; and
4. 24 percent of respondents had access to their employer’s computer system or network after their departure from the company.

(see also State of the Endpoint IT Security & IT Operations Practitioners in the United States, United Kingdom, Australia, New Zealand & Germany sponsored by Lumension; Independently conducted by Ponemon Institute LLC; Publication Date: November 30, 2009)(avaliable at http://www.ponemon.org/local/upload/fckjail/generalcontent/18/file/Lumension%20State%20of%20the%20Endpoint%20FINAL%203.pdf).

Organizational Structure

• Which individual(s) oversee HIPAA privacy and security issues — state their names and titles of the: (1) the private officer; (2) the security officer; and (3) principle contact in the event of a security incident.
• Do you have written policy and/or a job description for the privacy, security and security incident response contact person?
• Does the organization conduct internal monitoring regarding HIPAA compliance through: (1)  an internal privacy security team; (2) an external third-party; (3) or there is no HIPAA compliance monitoring?
• Briefly describe what protected health information your organization maintains and where said information is retained (i.e. application, systems, database)?
• Does business associate have a reporting mechanism for potential privacy or security breaches?
• If a reporting mechanism exists, who is responsible for addressing potential breaches and what is the chain of command within your organization?
• Please specify any reported security breaches to a covered entity, government entity, and/or consumers in the last 3 years?
• Does the business associate have an Information Technology (IT) group oversee risk management related to PHI stored in business associate systems?
• Please provide a list of individuals responsible for such oversight activity along with their credentials/certifications.
• What responsibilities do individuals in your legal department have related to HIPAA compliance?
• Does your organization have a business continuity plan to address preserving access to and integrity of PHI in the event of a disaster or other catastrophic event?

Administrative Structure

• What policies (and procedures) are available specifically addressing HIPAA privacy and security rules and compliance including the following:
  1. Risk Management;
  2. Risk Assessment and Application Criticality Analysis (FIPS 200);
  3. Physical Security;
  4. Encryption;
  5. Remote Access;
  6. Media and Document Destruction;
  7. Change Control/ Patch Management;
  8. Acceptable Use (Email, Portable Media, Software, Company Resources);
  9. Training and Security Reminders;
  10. Antivirus and Workstation Security;
  11. Unique User Identification;
  12. Audit and Log Monitoring;
  13. Security  Incident;
  14. Contingency and Emergency Access; and
  15. Workforce Clearance, Sanction, and Access Management.
• Who or what group within the organization is responsible for creating and updating these policies?
• When were the organization’s policies last updated?
• How often have any of these policies been updated?
• Are new employees trained to follow these policies and procedures?
• How frequently are existing employees re-trained on existing policies and procedures?
• How frequently are existing employees trained regarding updates in HIPAA rules?
• How are personnel screened in order to grant certain levels of access to PHI?
• Does the organization have a formal security incident response plan to address potential breaches of security that include at a minimum: (1) roles and responsibilities; (2) isolate affected system; (3) preserve evidence; (4) restore compromised system from known safe backups; and (5) post incident response report including identification of lessons learned and other mitigating controls may be indicated based on the incident?
• Does the organization require business partners to comply with its privacy and security policies?
• Does organization ever send PHI via email or ftp (file transfer protocol)?
• Does the organization have policy or procedures related to de-identifying PHI for use in advertising, marketing, educational programs?
• What policies and procedures exist regarding notification in the event of a breach?

Physical Structure

• How is PHI stored within the organization (i.e. fixed server databases/hard drives versus removable media such as backup tapes)?
• Does your company of a physical security plan?
• What types of controls exists to limit access into buildings containing servers that host PHI?
• What types of controls exists to limit access within buildings to rooms housing servers containing PHI?
• Who has access to facilities containing PHI, and what process exists to grant these individuals access?
• What environmental controls exist to protect PHI from destruction?
• To the extent PHI is physically maintained, does the organization employ shredders or other destroying devices for confidential PHI containing documents?  Do you train and document the training of employees on the use of shredders?

Technical Structure

• What types of security and encryption protect portable media containing PHI? (Portable media should always be encrypted.)
• What types of security exists to protect PHI as it flows to and is accessed at remote workstations?
• Describe the data flow “life-cycle” of PHI through the organization’s information systems.  (This should cover hosting services, software development, quality assurance, other issues.)
• Does the organization have routine maintenance protocols that backup, delete, relocate, or otherwise impact data containing PHI?
• What types of audit mechanisms exist to track access and transmission of PHI by internal or external users?  Typically audit logs include a timestamp, a unique user account, data accessed/modified/created, and the location of the user.
• How often are these audit mechanisms used to detect abnormal use?
• Do automatic triggers exist to notify the organization of abnormal PHI use?
• Does the organization prevent browsers with un-patched security vulnerabilities from accessing the company’s information system?

Compliance History and Future Developments

• Has the organization had any security incidents in the past 5 years?  How many and when?
• Has business associate received any negative press related to privacy or security issues in the past 5 years?  How many and when?
• What if any HIPAA security and privacy litigation has business associate been party to in the past 5 years?  Describe the timeline, the circumstances, and the outcome.
• Has business associate conducted risk assessments and vulnerability assessments through independent third parties?  When was the last assessment done?
• Has business associate developed its business off-shore?  If so, are the off-shore business associate facilities ISO 17799 certified?
• Does business associate have new technologies on the horizon that involve PHI, and what if any safeguards are contemplated to protect this data?

Key Terms

Advanced Encryption Standard (AES) – specifies the FIPS 140-2 approved cryptographic algorithm that can be used to protect electronic data.

Business Associate – a third party that acts on behalf of a covered entity by performing a function or activity that HIPAA’s Administrative Simplification rules regulate or that provides certain services (e.g., legal or consulting services) that involve the use or disclosure of individually identifiable health information.

Covered Entity – a health plans, health care clearinghouses, health care providers, and endorsed sponsors of the Medicare prescription drug discount care that conduct covered transactions electronically.  Covered entities are subject to HIPAA’s Administrative Simplification mandates.

Encryption - Cryptographic transformation of data (called “plaintext”) into a form (called “ciphertext”) that conceals the data’s original meaning to prevent it from being known or used. If the transformation is reversible, the corresponding reversal process is called “decryption”, which is a transformation that restores encrypted data to its original state.

HIPAA (The Health Insurance Portability and Accountability Act) – mandates the use of standards for the electronic exchange of health care data; to specify what medical and administrative code sets should be used within those standards; to require the use of national identification systems for health care patients, providers, payers (or plans), and employers (or sponsors); and to specify the types of measures required to protect the security and privacy of personally identifiable health care information.

NIST (National Institute of Standards) - an agency in the Technology Administration that makes measurements and sets standards as needed by industry or government programs.

Protected health information (PHI), under the US Health Insurance Portability and Accountability Act (HIPAA), is any information about health status, provision of health care, or payment for health care that can be linked to an individual. This includes any part of a patient’s medical record, diagnosis,  and/or payment history.

PHI identifiers include:

1. Names;
2. All geographical subdivisions smaller than a State, including street address, city, county, precinct, zip code, and their equivalent geocodes, except for the initial three digits of a zip code, if according to the current publicly available data from the Bureau of the Census: (1) The geographic unit formed by combining all zip codes with the same three initial digits contains more than 20,000 people; and (2) The initial three digits of a zip code for all such geographic units containing 20,000 or fewer people is changed to 000;
3. Dates (except year) for dates directly related to an individual, including birth date, admission date, discharge date, date of death; and all ages over 89 and all elements of dates (including year) indicative of such age, except that such ages and elements may be aggregated into a single category of age 90 or older;
4. Phone numbers;
5. Fax numbers;
6. Electronic mail addresses;
7. Social Security numbers(SSN);
8. Medical record numbers;
9. Health plan beneficiary numbers;

10.  Account numbers;

11.  Certificate/license numbers;

12.  Vehicle identifiers and serial numbers, including license plate numbers;

13.  Device identifiers and serial numbers;

14.  Web Universal Resource Locators (URLs);

15.  Internet Protocol (IP) address numbers;

16.  Biometric identifiers, including finger, retinal and voice prints;

17.  Full face photographic images and any comparable images; and

18.  Any other unique identifying number, characteristic, or code (note this does not mean the unique code assigned by the investigator to code the data)

Table 2 – NIST SP 800-66 HIPAA Security Compliance Guidance

Business Associate and Covered Entity HIPAA Compliance — Auditing Questions and NIST 800-53 Security Controls. originally appeared on Law Blog 2.0 on November 29, 2009.

          

Next year should be interesting.  From Red Flag compliance, federal breach reporting requirements, significantly augmented HIPAA penalties, and HIPAA security standards that are based on NIST guidelines will change the traditional compliance model for Covered Entities and Business Associates.  Hot topics for enforcement next year (based on recent CMS audits of their business partners) will likely be in the areas encryption of portable media devices, remote access by employees to protected health information, and failure to document a rational risk management process.

1. Electronic Health Records and Interoperability.  The American Recovery and Reinvestment Act of 2009 (ARRA) allocated $19 billion over a five-year period to help providers purchase and implement electronic health record systems.  Of more concern to providers, however, are the penalties for failing to adopt (and make meaningful use) of an EHR system before 2015  when providers will face a reduction in their Medicare fee schedule of -1% in 2015, -2% in 2016, and    -3% in 2017 and beyond.  There are many willing health care providers that want to implement EHR systems.  However, whether the EHR systems work as intended and actually meet the government’s meaningful use requirements remains an open question.
2. Federal Breach Reporting Requirements.  Covered entities will be on the spot for ensuring that their business associates report security breaches to them in a timely manner.  Covered entities must then document their risk analysis and their conclusion as to why or why not a security incident should be reported to members.  This analytic process should be incorporated into your security incident policy and procedures as soon as practicable.  Due diligence of some sort may be indicated for those business associates who have heretofore not been meeting their obligations to comply with the requirements of the HIPAA Privacy and Security regulations.  Moreover, some members of Congress are not entirely happy with the harm standard; they favor a strict acquisition based reporting obligation.  If this happens, we can expect to see a lot of security breach reports, many plaintiff class actions, and further federal legislation in reaction to the perceived threat of riskless security breaches.
3. HIPAA Security and Privacy Regulations will begin to look a lot like FISMA.  The Federal Information Security Management Act of 2002 (“FISMA”, 44 U.S.C. § 3541, et seq.) requires each federal agency to develop, document, and implement an agency-wide program to provide information security for the information and information systems that support the operations and assets of the agency, including those provided or managed by another agency, contractor, or other source.  NIST prepared a series of guidelines to help federal agencies comply with FISMA.  These guidelines address administrative, physical and technical safeguards. We expect HHS to largely remove itself as the source of all knowledge as to what is specifically required to with respect to administrative, physical and technical safeguards and utilize NIST standards as the new guideposts for evaluating the effectiveness of a covered entity’s risk management program and mitigating safeguards.  For example, CMS’s auditing materials used to audit CMS’s business partners are very similar to NIST privacy and security guidance.  Unlike HIPAA, NIST standards are very specific and include well over 20 core publications.  You can get a head start on your spring reading by reviewing SP 800-66 Rev 1, An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule (Oct. 2008).
4. Encryption and Remote Access.  2010 will be the year where many organizations will begin layering encryption controls onto portable media, laptops, and publically accessible workstations.  Whether an encryption product has been certified as FIPS 140-2 should be a key consideration when purchasing a new encryption solution.  You can find out whether a product you are considering has been certified at http://csrc.nist.gov/groups/STM/cmvp/validation.html.  In addition, you can get a sample implementation policy produced by the manufacturer at the time of certification stating how the product should be deployed.  The FIPS 140-2 standard is an information technology security accreditation program for cryptographic modules produced by private sector vendors who seek to have their products certified for use in government departments and regulated industries (such as financial and health care institutions) that collect, store, transfer, share and disseminate “sensitive, but un-classified (SBU)” information.  Proper encryption policies and procedures rely on ensuring that users are properly trained to follow the precise process dictated by the encryption product’s documentation.  The failure to do so will compromise a company’s encryption solution.   The elephant in the room remains remote access to systems containing sensitive information by users from their home computers.  Unfortunately, although remote access is convenient for employer and employee alike, its safeguards are expensive and difficult to implement.  It is not clear what level of control must be exercised over an employee working from home on his/her remote computer.
5. Watch for Further Enforcement Actions.  Enforcement activities by the OIG provides some insight into what is important for avoiding HIPAA Privacy and Security liability.  For example, after the Providence Health System case we know encrypting portable media is a hot topic.  And following the CVS enforcement action, most organizations are making sure that their employees have easy access to shredders and training on how to properly destroy documents.
6. Red Flag Compliance.  The Federal Trade Commission (FTC) has delayed the compliance deadline of the Red Flags Rule yet again — this time until June 1, 2010.  The AMA is pushing the FTC and Congress to republish the rule so that there is sufficient opportunity to formally comment and state AMA’s objections to physician inclusion in the program.  However, I would not count on the Red Flag Rules being delayed again.

Key Issues in Privacy and Security for 2010 originally appeared on Law Blog 2.0 on November 17, 2009.

          

HHS

On October 7, 2009 HHS announced proposed rulemaking to modify the HIPAA privacy rule to comply with Section 105, Title I of the Genetic Information Nondiscrimination Act of 2008 (GINA)  regarding the privacy and confidentiality of genetic information.  The prosed rule is found here HIPAAPRIVACYRULE13343.0.E9-22492. The HIPAA Privacy Rule establishes national standards to protect individuals’ medical records and other personal health information and applies to health plans, health care clearinghouses, and those health care providers that conduct certain health care transactions electronically.  Similarly Congress by enacting GINA seeks to protect the genetic privacy of individuals — GINA creates ‘‘a national and uniform basic standard [that] is necessary to fully protect the public from discrimination and allay their concerns about the potential for discrimination, thereby allowing individuals to take advantage of genetic testing, technologies, research, and new therapies.’’ (GINA section 2(5).)

The HIPAA Privacy Rule requires a covered entity (and beginning next year Business Associates) to implement reasonable and appropriate administrative, technical and physical safeguards to protect the privacy of personal health information (PHI).  The HIPAA privacy rule more generally sets limits and conditions on the uses and disclosures that may be made of such information without patient authorization. The Rule also gives patients rights over their health information, including rights to examine and obtain a copy of their health records, and to request corrections.  The Department of Health and Human Services (HHS) proposed to modify provisions of the ‘‘Standards for Privacy of Individually Identifiable Health Information’’ (Privacy Rule), issued under the Health Insurance Portability and Accountability Act of 1996 (HIPAA).  The purpose of these proposed modifications is to implement Section 105 of Title I of the Genetic Information Nondiscrimination Act of 2008 (GINA) regarding the privacy and confidentiality of genetic information, as well as to make other less technical changes to the HIPAA Privacy Rule.

GINA specifically prohibits discrimination based on an individual’s genetic information with respect to both health coverage and employment.  It is improper to use an individuals genetic information as basis for determining –

1. health coverage,
2. group premiums,
3. eligibility for insurance,
4. eligibility for employment, and/or
5. premiums for individuals and Medicare insurance policy markets.

HHS proposes to modify the HIPAA Privacy Rule to:

(1)    Explicitly provide that genetic information is health information for purposes of the Rule;
(2)    prohibit health plans from using or disclosing protected health information that is genetic information for underwriting purposes;
(3)    revise the provisions relating to the Notice of Privacy Practices for health plans that perform underwriting;;
(4)    make a number of conforming modifications to definitions and other provisions of the Rule; and
(5)    make technical corrections to update the definition of ‘‘health plan.’

In addition Section 105 of the Genetic Information Nondiscrimination Act of 2008 (“GINA”) provides that a group health plan or health insurer may not use or disclose genetic information for purposes of underwriting. These provisions became effective on May 20, 2009.   On October 7, 2009, the Department of Health and Human Services (“HHS”) issued proposed regulations on how Section 105 will impact the HIPAA privacy regulations and HIPAA covered entities.  Additional regulations issued on October 7, 2009 interpreting other health plan aspects of will be discussed in a subsequent client Alert. ’

The proposed regulations would extend GINA’s prohibition on using and disclosing genetic information for underwriting purposes to all health plans that are subject to the HIPAA privacy regulation. T he prohibition would extended long-term care policies, certain public benefit programs, such as Medicare and Medicaid, military health care programs, and limited scope dental and vision benefits so that all provisions would apply uniformly to all health plans covered by the HIPAA privacy regulation.

Comments on the proposed rule will be considered if receive no later than December 7, 2009.  We recommend that a company documents should also be updated to reflect the new GINA provisions, including the health plan’s policies and procedures. Depending on the services that are provided by a business associate and the language of existing business associate agreements, applicable business associate agreements may also need to be updated. Finally health plan sponsors may also consider whether adding protective language in their health plan documents is also appropriate.

HHS Announces Proposed Rulemaking to modify the HIPAA privacy Rule to Comply with Section 105 of Title I of the Genetic Information Nondiscrimination Act of 2008 (GINA) originally appeared on Law Blog 2.0 on October 15, 2009.

          

Congress Complains

The most important feature of the new breach regulations from a compliance perspective is the risk of harm standard that qualifies the meaning of a “breach” in the HITECH Act and guidance issued by the Secretary on April 17, 2009. (See HITECH Act at § 13400(1)).  A breach that “compromises the security or privacy of the [PHI]” is a breach that “poses a significant risk of financial, reputational, or other harm to the individual.” (45 C.F.R. § 164.402)  The risk of harm standard requires that a covered entity undertake a risk assessment of the potential harm to the affected individuals, and based upon this assessment; determine in good faith whether it is necessary to notify the individual(s) of the breach.

Generally in the event of a “breach” of “unsecured” PHI, a covered entity must notify each individual whose unsecured PHI has been, or is reasonably believed to have been, breached. (45 C.F.R. § 164.404(a)(1).)   Despite the obvious utility of the new harm standard, a few privacy advocates (and four United States congressmen) have expressed displeasure with the new HHS harm standard.   An October 1st letter from congressional leaders sent to HHS Secretary Sebelius argues that the ARRA did not imply a harm standard in the breach notification requirements, and requests that HHS repeal the harm standard that was included in the interim final regulations on Breach Notification for Unsecured Protected Health Information.

For a copy of the letter, sebelius_letter.  However, many states use a standard similar to the harm standard under the federal Breach Reporting Rules (including New York,* Michigan and New Jersey).  Only six states have a strict acquisition based standard; of those six states, only a couple of these states link the definition of encryption to FIPS 140-2 (Federal Information Processing Standard).  The letter was signed by Henry A. Waxman, Chairman of the Committee on Energy and Commerce (Democrat, California); Charles B. Rangel, Chairman of the Committee of Ways and Means (Democrat, New York); John D. Dingell, Chairman Emeritus of the Committee on Energy and Commerce (Democrat, Michigan); and Frank Pallone, Jr., Chairman Subcommittee on Health Committee on Energy and Commerce (Democrat, New Jersey).

*Note I listed New York  in error as a risk based/ harm based state.  I appreciate the careful attention of harley@cdt.org at blog.cdt.org for his comment.  A complete listing of acquisition based states is avaliable at: http://law2point0.com/wordpress/2009/09/15/50-state-security-breach-notice-law/ and this would include both New York and California.

Four Members of Congress Complain to Secretary of HHS About the Harm Standard originally appeared on Law Blog 2.0 on October 12, 2009.

          

Analysis of OMB No. 0990-0346 – HHS’s Security Breach Reporting Form

The form itself offers some insight into HHS’s understanding of security breaches and how HHS believes breaches can be mitigated and/or avoided altogether.  The following are what I consider to be the most interesting questions and potential responses pre-populated within the form:

1. HHS has defined seven categories of breaches within the form: theft, loss, improper disposal, unauthorized access, hacking/IT incident, other, and unknown.  Theft, loss, and improper disposal are breaches that can be easily mitigated by encryption or by following the guidelines referenced by HHS for the destruction of paper/and electronic media;
2. The “locations” where a breach may occur, identified by HHS, include: laptops, desktops, network servers, e-mail, other portable electronic devices, electronic medical records, paper, and other.  Again this question and the pre-populated responses echo HHS’s interest in encryption for data stored on laptops, desktops, and other portable media devices.  Moreover, next to loss of PHI related to theft of computer equipment, e-mail runs a close second as the next biggest source of breaches involving PHI.  It is very easy for someone to mistakenly email a message to the wrong person;
3. The form identifies four categories of PHI–demographic information, financial information, clinical information and other.  Demographic information and especially financial information are high value targets to potential identity thieves; and
4. Probably the most interesting question, from a planning perspective, requires the covered entity identify whether any of the following security controls were in place before the security incident: firewalls, packet filtering (router based), secure browser sessions , strong authentication , encrypted wireless , physical security, logical access controls, anti-virus software, intrusion detection, and biometrics.

This list of security controls is an odd combination of specific types of security controls (e.g. packet filtering router) and general categories of security controls (e.g. physical/ logical access controls).  I find inclusion of biometrics and the exclusion of two factor authentication (a more general category) unusual – the utility of biometric access controls relate more generally to creating systems of two factor authentication.  Two factor authentication techniques are based on any two of the following three types of methods: something you know, something you are, and something you have.  One common example of two factor identification is the use of a security token that generates a seemingly random number in combination with a pin and a password to authenticate a user.  Biometric methods of identification, which include fingerprint scanners, facial recognition, and retinal scanners, are either too expensive to implement as a broad-based solution or are poor quality consumer oriented solutions.

In all, it is obvious what the hot button issues are that may get the enforcement body’s (Office of Civil Rights) attention and more importantly how to avoid them: (i) encrypting portable media, (ii) firewalls, (iii) proper document destruction procedures, (iii) the existence of a physical security plan, (iv) two factor authentication, and (v) antivirus.

The form should be filled out with diligence.  The form contains an attestation that the information provided is accurate, and acknowledgement that the Office of Civil Rights (“OCR”) may be required to release information provided via the form pursuant to the Freedom of Information Act, some of the information will be posted to HHS’s web site, and tOCR will use the information to provide an annual report to Congress required by the HITECH Act.

Content of the Notice to the Secretary of HHS for a Reportable Security Breach originally appeared on Law Blog 2.0 on October 12, 2009.

          

HHS Security Breach Notice Regulations - Update

A series of privacy advocates have expressed displeasure with the HHS “harm standard” as articulated in the recent Covered Entity .  However, I believe the “harm standard” is reasonable and appropriate.  One recent article is available here (published by computer world): HHS guts health-care breach notification law, groups warn Posted using ShareThis

I am a little unclear as to why privacy advocates and security vendors believe that the harm standard, found within the new HHS regulations for security breaches, in any way hampers the HITECH Act’s security breach notice rule for covered entities and business associates.  Many states use a similar risk based type analysis, in fact only seven states have a strict acquisition based standard, of those only a couple of these states link their definition of encryption to FIPS 140-2.*  In comparison to risk based states where one assesses the potential risk to a consumer resulting from theft of sensitive information, the federal standard is more helpful in the sense that it highlights key criteria to be evaluated in assessing risk to consumers.

*I am not certain on this, but I believe the most problematic state is California.  California includes health information within the definition of personal information, California references FIPS 140-2, California is an acquisition based state, and guidance documents issued by the state are extremely draconian.

Second, implementing a FIPS 140-2 approved encryption system is an expensive and complicated process — it seems reasonable that HHS should temper FIPS 140-2 with a harm standard analysis.  As many covered entities have started to dissect the requirements of what would constitute acceptably encrypted data under the HITECH act they have quickly realized that process of implementing what is largely a FISMA (Federal Government/ Military) based encryption standard presents many problems.  FIPS approved algorithms and processes require precise configuration; such systems are designed to fail closed.  Failing closed means denying access — this could be a good thing with money but a bad thing when dealing with clinical data in an emergency situation.  Security controls in the health care industry are a delicate balance of confidentiality, integrity and availability. (http://law2point0.com/wordpress/2009/09/15/50-state-security-breach-notice-law/).  Pushing out government grade security safeguards too fast could create serious issues in the event a provider needs immediate access to patient records but hospital A cannot communicate with hospital B due to a conflicting encryption schema.

Without the harm standard, covered entities would be forced into over-reporting incidents — over-reporting can be just as damaging as not reporting any security incidents.  There are two studies that help to put the “harm” or risk-based standard for security breach reporting in an appropriate (real-world) context.
The first study is a report prepared by the General Accounting Office (GAO) from 2007 entitled PERSONAL INFORMATION — Data Breaches Are Frequent, but Evidence of Resulting Identity Theft Is Limited; However, the Full Extent Is Unknown (the report is available for free at http://www.gao.gov/new.items/d07737.pdf).  This report evaluated the 24 largest breaches reported in the media from January 2000 through June 2005.  The study found that:

1. In only three instances was there evidence of fraud on existing accounts and in only one instance of the three identified cases did the GAO find evidence of unauthorized creation of a new account;
2. For 18 of the breaches, no clear evidence was uncovered linking the breach to identity theft; and
3. In the remaining two cases there was insufficient information to make a determination.

A second article, by S. Romanosky, R. Telang, and A. Acquisti, entitled Do Data Breach Disclosure Laws Reduce Identity Theft? (available for free at  http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1268926) summarizes the debate surrounding security breach notification laws and their impact.  The authors’ analyses reveal a modest effect of security breach disclosure laws in reducing identity theft rates by approximately 2%.  However, this article also notes that over-reporting has many negative consequences — including unnecessary costs and desensitizing consumers such that when a real incident that they should take notice of is ignored.

The FIPS-140-2 standard is a Federal Standard and the guidance cited by HHS (OMB Memorandum M-07-16 is also a federal standard (available at http://www.whitehouse.gov/OMB/memoranda/fy2007/m07-16.pdf)).  The OMB the guidance and the FIPS 140-2 are both compoennts of the federal government program to protect against harm resulting from a security breach.  It seems logical if that we are following a FISMA structure that OMB Memorandum M-07-16 should be considered when assessing the scope and consequences of a security breach.

The harm standard may result in fewer notices, in some states where there are exceptions for HIPAA covered entities for some provisions of state reporting requirements, but absent an applicable exception an entity could still be bound by the state standard and the federal standard.  Many states are including health information within the definition of personal information; even so it is frequently the case that when health information is compromised the triggering elements for a given state’s reporting statute are present within the compromised health data.  Unfortunately, the end result will likely be a negligible  reduction in notice unless the seven states and the DC that have an acquisition based standard move to a risk based / harm based analysis.  In my opinion an acquisition based standard reaches the wrong result for both consumers and companies.  The one benefit will be that the Federal standard does provide a rational framework for entities absent other guidance that can be used to frame analysis of a security incident and what mitigation efforts are appropriate.

Fear Mongering or Legitimate Criticism — “HHS guts health-care breach notification law, groups warn” originally appeared on Law Blog 2.0 on September 22, 2009.

          

The Ninth Circuit’s decision is certainly inconsistent with the Seventh Circuit’s analysis, to the extent the Seventh Circuit based liability under the CFAA on an agency theory where the servant (the employee) unilaterally aquireed an interest inconsistent with his principle (his employer) the serverant (the employee) lost his right (authorization) to access his employer’s (the principle’s) protected computer. The operative language cited in Citrin (following the Restatement (Second) of Agency §§ 112, 387 (1958): “Unless otherwise agreed, the authority of the agent terminates if, without knowledge of the principal, he acquires adverse interests or if he is otherwise guilty of a serious breach of loyalty to the principal.”

Because the employee in LVRC Holdings was authorized to use the company computer and to access the information, he did not violate the CFAA regardless of his motivation. The opinion most likely would have been different under a slightly different factual scenario. First, if the employer had a policy prohibiting employees from emailing company data to their personal email accounts or requiring employees to return or destroy confidential information upon the conclusion of their employment then the employee would have exceeded his level of authorization regardless of whether his interests were aligned or not aligned with his former employer. In LVRC Holding the employee was authorized to use the company computer and to access the information, he did not violate the statute, under the 9th Circuit’s decision the former employee’s motivation is irrelevant.

I believe the conclusion reached by the 9th circuit and 7th circuit can be rationally reconciled based on the factual differences between the two cases. The Court in Citrin properly reasoned that congress intended that the CFAA should apply to disgruntled employees in certain situations but the 9th circuit’s decision provides a better basis for defining culpability under the CFAA. Courts do not want to engage in mind-games to assess the employee’s intention (or motivation) in order reach a conclusion regarding whether an employee’s conduct violated or did not violate the CFAA

The CFAA was intended to reach:

Attacks by virus and worm writers, on the one hand, which come mainly from the outside, and attacks by disgruntled programmers who decide to trash the employer’s data system on the way out (or threaten to do so in order to extort payments), on the other. If the statute is to reach the disgruntled programmer, which Congress intended by providing that whoever “intentionally accesses a protected computer without authorization, and as a result of such conduct, recklessly causes damage” violates the Act, 18 U.S.C. § 1030(a)(5)(A)(ii)attacks by virus and worm writers, on the one hand, which come mainly from the outside, and attacks by disgruntled programmers who decide to trash the employer’s data system on the way out (or threaten to do so in order to extort payments), on the other. If the statute is to reach the disgruntled programmer, which Congress intended by providing that whoever “intentionally accesses a protected computer without authorization, and as a result of such conduct, recklessly causes damage” violates the Act, 18 U.S.C. § 1030(a)(5)(A)(ii).

However, the CFAA cannot become a catchall basis for finding criminal and/or civil liability in the absence of other relevant legal authority.

9th Circuit Decision in LVRC Holdings Rejects 7th Circuit’s Holding in Citrin Based on a Motivation Theory of Liability Under the Computer Fraud and Abuse Act originally appeared on Law Blog 2.0 on September 18, 2009.