Despite the Federal Governments incentives, State HIE grants, new privacy/security regulations, and regulations on how to make meaningful use of an EHR there remain a number of serious issues that will need to be addressed before we can expect a National Health Information Network as envisioned by the Bush administration.  The personal health record and electronic health record distinction created by the Federal government has created a dichotomy between the official and personal health record.  The FTC is responsible for defining appropriate security measures for personal health records and HHS responsible for defining appropriate security measures for EHRs.  Most EHRs contain information that would be defined as protected health information and be subject to the HIPAA Privacy and Security regulations.

The following is a summary of the implementation issues that will need to be addressed by the Federal Government, health-care providers and technology vendors:

• Ownership. Ownership of the electronic health record and/or the personal health record remains unclear.  There is significant disagreement among providers and privacy advocates as to who owns a person’s medical data;
• Patient Rights. Similarly, if an individual owns his/her medical record should he/she be permitted to change the record, add material, and/or block portions of the record from being shared with a health care provider.  On the other hand are there components of an individual’s medical record that should not be available to the patient;
• Proprietary Formats. Electronic medical records largely remain in proprietary formats relegated to various data silos with a small group of providers.  Some larger providers have entered relationships with Google Health and/or Microsoft Health Vault.  However, absent the existence of an information sharing agreement between the provider, the PHR vendor (in this case) and the patient there remains no unified medical record that can be created and then shared with all;
• Interoperability. Ensuring the interoperability of a diverse array of electronic medical record systems remains a serious limitation with many EHR solutions.  Organizations tend to stick to the old data structures implemented on historical mainframes and disregard interoperability as a key issue when implementing an EHR.  While theoretically versions of the same EHR should be interoperable in house customizations in many instances break any inherent interoperability that may exist within EHR systems of the same type.  There are some promising projects on the horizon like the open source connect initiative, a java framework for defining gateways and interfaces for an organization to communicate with the NHIN;
• User Acceptance. Building consumer and physician confidence in the use of an electronic medical record system remains difficult;
• Meaningful Use. Developing criteria for the government to assess whether any given provider is a meaningful user of his/her medical record system.  The real value of an EHR is typically analyzed retrospectively such data is suspect in the absence of an experimental control group and the inability to evaluate the technology without accounting for other variables that may affect the result;
• Long Term Data. Compiling long term data to evaluate the effectiveness (meaningful use) of various EHR components will be necessary to drive investment by the private sector; there are some proof of concept implementations for certain categories of providers.  Such examples are rare given the diverse array of health care providers and the technology used to store data related to any given patient;
• Access Controls. There are no industry standards for delineating (describing) and administering rights with respect to an individual’s personal health record.  Various technologies like private key / public key encryption, certificate authorities, and algorithms to ensure the confidentiality and integrity of protected health information exist, but these systems are poorly understood by most health information technology departments even at the largest providers;
• Appropriate Security Safeguards. The complex array of state and federal laws make defining the appropriate mix of administrative, physical and technical safeguards an intractable problem.  First movers that take the initiative to define how to protect patient data from disclosure, modification while ensuring the availability of this information in the event of an emergency, are subject to government second guessing; and
• Legal Liability and Storage Limitations. While storage is cheaper than ever, there is not enough space to store all data related to the care of a patient. It is not clear what information must be retained so that a court can subsequently evaluate the quality of care in any given scenario where a physician may be sued for malpractice.  One example are DICOM (see http://en.wikipedia.org/wiki/Digital_Imaging_and_Communications_in_Medicine)  medical images that require 100’s of megabytes of data, if multiple versions of a medical record must be maintained the storage requirements for an individual’s medical record will expand at an exponential rate.  Some algorithmic methods to conserve space for storing data cannot be used.  The application of irreversible compression technology potentially makes an EHR subject to regulatory review by the FDA.

Related Links:

Discussion of MSFT Health Vault Support of  the Continuity of Care Record (CCR) and the Continuity of Care Document (CCD).

Discussion of Google Health’s Implementation of a Subset of the CCR.

Sample DICOM Images

Definitions

Continuity of Care Record -

The CCR  is a patient health summary standard that includes core health information about a patient.  The CCR is not intended to represent a patients entire medical history.  The CCR standard is based on XML.  An XML scheme to be used to verify the proper formatting of a CCR document can be purchased along with a description of the standard from ASTM International.

DICOM-

The Digital Imaging and Communications in Medicine standard created by the National Electrical Manufacturers Association (NEMA) to aid the distribution and viewing of medical images, such as CT scans, MRIs, and ultrasound.

Related Blogs

          

The Elephant in the Room – Implementation Issues for a National Health Information Network from HIMSS 2010 originally appeared on Law Blog 2.0 on March 12, 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

Related Blogs

• The collapse of China's English-teaching schools » The Peking Duck
• Irish Mr. English : Unleashed Online
• Idea Lab: Full English Breakfast from Scratch
• Language Log » Chinese Endangered by English?
• Toy Tokyo x Secret Base x Ron English X-Ray McSupersized Figure …

          

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.

Health Information Exchange

A Health Information Exchange (HIE) is a network of healthcare information systems electronically connected across organizations within a region or a community using a common communication protocol for the transparent exchange of health information.  HIEs provide the capability to move clinical information among disparate health care information systems while maintaining the meaning and context of the data being exchanged.  The goal of an HIE is to facilitate access to and retrieval of clinical data to provide safer, more timely, efficient, effective, equitable, patient-centered care.  HIEs are also useful for public health authorities to assist in analysis of the health of a population.  Federal Health Architecture is intended to deliver free, scalable solution to help organizations to tie health information systems into the NHIN.  Thus far the project has yielded at least one success (outside of the federal government) where data have been successfully transferred between a civilian hospital and the VA.

In February 2009, the CONNECT software gateway was used for the first time in a limited production environment when the SSA began receiving live patient data from MedVirginia through the NHIN.  The agencies built CONNECT using open source components, made it available under an open source license in order to encourage innovation and ease the cost of adoption.

Key issues with testing and/or implementing CONNECT include:
•    Too many manual steps where human typing errors can occur (setting environmental variables incorrectly, typos, setting incorrect directories, etc);
•    Having to manually edit scripts and different files to update with IP address, add XML pieces, etc;
•    Once Gateway is set-up, no way to communicate to another Gateway unless you set-up another Gateway;
•    Log files are confusing; and
•    Need better out of box experience.

The license found at the Connect websites allows the user many rights (including the right to withhold developments done privately from the project as a whole).  Many open source libraries require the community to give back new features/ source code to the project.  Guidance and documentation on how to connect into the NHIN framework is available at http://www.connectopensource.org/display/NHINR21/Guidance+on+Joining+the+NHIN+Using+the+CONNECT+Gateway.  The interface schema for the Connect gateway is available at http://www.connectopensource.org/download/attachments/14450700/CONNECT_+Release_2_1_Integrated_Interface_Description_Document_070709.pdf?version=1.  Currently the software can be compiled and run in a MSFT Windows environment, however, organizations including the open source community and Red Hat are working on a *nix version what will allow the distribution of a VMware image for easy testing and review by organizations that are potentially interested in using the software for resolving internal communication issues in large health systems and also to connect to the NHIN.  The software is available for download at http://www.connectopensource.org/display/NHINR21/Release+2.1+Home.
The success of NHIN thus far was made possible by the Federal Health Architecture and open source software.  The Federal Health Architecture (“FHA”) is an E-Government Line business initiative.  The FHA made software, called CONNECT and supporting documentation available at www.connectopensource.org, available to help health information technology systems communicate to the Nationwide Health Information Network (NHIN), a federal initiative to facilitate the electronic exchange of health information.

The NHIN seeks to achieve these goals by:
•    Developing capabilities for standards-based, secure data exchange nationwide;
•    Improving the coordination of care information among hospitals, laboratories, physicians offices, pharmacies, and other providers;
•    Ensuring appropriate information is available at the time and place of care;
•    Ensuring that consumers’ health information is secure and confidential;
•    Giving consumers new capabilities for managing and controlling their personal health records as well as providing access to their health information from electronic health records (EHRs) and other sources; and
•    Reducing risks from medical errors and supporting the delivery of appropriate, evidence-based medical care.

The FHA is responsible for:
•    Leveraging federal expertise by creating a federal health information sharing environment;
•    Supporting federal efforts to develop and adopt health IT standards and services; and
•    Ensuring that federal agencies can seamlessly exchange health data among themselves, with state, local and tribal governments, and with private-sector healthcare organizations.

Organizations are now emerging at the community, state and federal level to detail/ create the necessary protocols that will allow health information exchange efforts to succeed.  These organizations (often called Regional Health Information Organizations, or RHIOs) are ordinarily geographically-defined entities which develop and manage a set of contractual conventions and terms, arrange for the means of electronic exchange of information, and develop and maintain HIE standards.  The NHIN is a commercial/government effort working to build an electronic infrastructure to allow data to move among different organizations and applications.

To promote a more effective marketplace, greater competition, and increased choice through accessibility to accurate information on healthcare costs, quality, and outcomes, the Office of the National Coordinator (ONC) is advancing the NHIN as a “network of networks” which will connect diverse entities that need to exchange health information, such as state and regional health information exchanges (HIEs), integrated delivery systems, health plans that provide care, personally controlled health records, Federal agencies, and other networks as well as the systems.

From the press release Federal Health Architecture Delivers Free, Scalable Solution Helping Organizations Tie Health IT Systems into the NHIN (dated April 2009)(http://www.connectopensource.org/display/Gateway/2009/04).

“The CONNECT software is the outcome of a 2008 decision by more than 20  federal agencies to connect their health IT systems to the NHIN.  Rather than  individually building software required to make this possible, the federal  agencies, through the Federal Health Architecture, created CONNECT. This shared  software solution can be used by each agency within its own environment. CONNECT  implements the core services defined by the NHIN including standards for  security to protect health information when it is exchanged with other trusted  health organizations.”

          

Open Source Programmers Collaborate To Improve the CONNECT Gateway originally appeared on Law Blog 2.0 on August 31, 2009.

ONC Grants Announced

The Office of the National Coordinator for Health Information Technology (ONC) has recently release more information on two grant programs.  The HITECH Act authorizes two grant programs: (1) a Health Information Technology Extension Program (Extension Program) and (2) the State Health Information Exchange Coopertive Agreement Program (Agreement Program).  This program provides grants for the establishment of Health Information Technology Regional Extension Centers that will offer technical assistance, guidance and information on best practices to support and accelerate health care providers’ efforts to become meaningful users of Electronic Health Records (EHRs). The consistent, nationwide adoption and use of secure EHRs will ultimately enhance the quality and value of health care.  The State Health Information Exchange Cooperative Agreement Program supports states and/or State Designated Entities (SDEs) in establishing health information exchange (HIE) capacity among health care providers and hospitals in their jurisdiction. Such efforts at the state level will establish and implement appropriate governance, policies and network services within the broader national framework to rapidly build capacity for connectivity between and among health care providers. State programs to promote HIE will help to realize the full potential of EHRs to improve the coordination, efficiency and quality of care.  For those interested ONC has made available a “grants primer” (avaliable at http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_10741_877878_0_0_18/Grants_Primer_update.pdf).  The primer will help a state find and apply for grants.

Health Information Technology Extension Program- Regional Centers

Grants are available to Regional Centers that are affiliated with a U.S.-based, nonprofit institution or organization, or an entity thereof, that applies for and is awarded funding under the Extension Program.  “The program anticipates that potential applicants will represent various types of nonprofit organizations and institutions with established support and recognition within the local communities they propose to serve.”

Principally Regional Centers will support health care providers with direct, individualized and on-site technical assistance in:

• Selecting a certified EHR product that offers best value for the providers’ needs;
• Achieving effective implementation of a certified EHR product;
• Enhancing clinical and administrative workflows to optimally leverage an EHR system’s potential to improve quality and value of care, including patient experience as well as outcome of care; and,
• Observing and complying with applicable legal, regulatory, professional and ethical requirements to protect the integrity, privacy and security of patients’ health information.

The Grant Process

“The application review and funding process will be separated into three application cycles, the dates of which are outlined in the table below.  Applicants will be required to submit a preliminary application that will undergo an objective review; successful preliminary applicants will be requested to submit a full application for merit review.  Successful full applications will result in award of four-year cooperative agreements.  Initial award decisions for Regional Centers are anticipated to be made in the first quarter of FY2010.  Additional awards are expected to be made as a result of two subsequent application cycles to be completed in FY2010.”

State Grants to Promote Health Information Technology Planning and Implementation Projects

“The State Cooperative Agreements to Promote Health Information Technology: Planning and Implementation Projects are to advance appropriate and secure health information exchange (HIE) across the health care system. Awards will be made in the form of cooperative agreements to states or qualified State Designated Entities (SDEs). The purpose of this program is to continuously improve and expand HIE services over time to reach all health care providers in an effort to improve the quality and efficiency of health care. Cooperative agreement recipients will evolve and advance the necessary governance, policies, technical services, business operations and financing mechanisms for HIE over a four year performance period. This program will build off of existing efforts to advance regional and state level HIE while moving towards nationwide interoperability.”

Participating states will also be expected to use their authority and resources to:

• Develop and implement up-to-date privacy and security requirements for HIE;Develop directories and technical services to enable interoperability within and across states;
• Coordinate with Medicaid and state public health programs to enable information exchange and support monitoring of provider participation in HIE.
• Remove barriers that may hinder effective HIE, particularly those related to interoperability across laboratories, hospitals, clinician offices, health plans and other health information exchange partners;
• Ensure an effective model for HIE governance and accountability is in place; and
• Convene health care stakeholders to build trust in and support for a statewide approach to HIE.

“Total funding for this initiative is $564,000,000. States (including territories) or their non-profit SDEs may apply, as designated by the state. No more than one award will be made per state. States may choose in enter into multi-state arrangements.”

See http://healthit.hhs.gov/portal/server.pt?open=512&objID=1331&parentname=CommunityPage&parentid=47&mode=2&in_hi_userid=11113&cached=true# for more information.

See also http://healthit.hhs.gov/portal/server.pt?open=512&objID=1333&parentname=CommunityPage&parentid=47&mode=2&in_hi_userid=11113&cached=true#

          

HITECH Grant Opportunities for Regional HIT Centers and HIE Cooperatives originally appeared on Law Blog 2.0 on August 24, 2009.

Meaningful Use

One example from the “Meaningful Use Matrix” requires that a provider – “Ensure adequate privacy and security protections for personal health information.”  This requires compliance with HIPAA Privacy and Security Rules.  Unfortunately the HIPAA Privacy and Security Rules are currently in a state of flux.  Assuming regulations are promptly promulgated the best case scenario requires a massive implementation effort of an EHR solution in less than a year.  The meaningful use matrix specifically requires a “security risk assessment”.  An entity “under investigation” cannot receive stimulus payments until the issue is resolved.  Length of investigation could also potentially include a missed payment (even if found “not guilty”).  The intent of this requirement was to disallow participation in HIT incentives if confirmed HIPAA violation goes unresolved.  The revised wording recommends – “that CMS withhold meaningful use payment for any entity until any confirmed HIPAA privacy or security violation has resolved.”

Potential issues arising from the tortured definition of meaningful use include:

1. Whether a company complies with the meaningful use requirements for 2011 will the company have to comply with the meaningful use requirements for EHRs adopted in 2013;
2. Whether a “confirmed HIPAA violation” is limited to situations where HHS has determined that a covered entity is not compliant and the covered entity was notified of said infraction potentially including a corrective action plan, or will a complaint be sufficient to meet the definition of a confirmed HIPAA privacy and/or security violation;
3. Whether requirements for interoperability and use cases for the EHRs can be implemented quickly (if not otherwise available in the EHR system);
4. Whether there will be a substantive change to the US Healthcare system.  A radical change could alter the playing field; and
5. Whether there will be sufficient data to support computerized provider order entries tied to electronic medication administration records and targeted order sets for chronic diseases including smoking, diabetes and hypertensive patients by 2011.

The lack of certainty and the resources needed to meet the EHR system meaningful use requirements will likely discourage hospitals and other providers from risking limited resources on an early EHR solution.  Given the absence of specificity it would seem that some may conclude that a wait and see approach is the most reasonable strategy.  Here the program requirements have been designed by politicians opposed to software engineers – can we expect that a hospital with limited resources would risk the investment to implement a system that may not work and may not meet some yet to be published future requirements.  Can we expect that EHR vendors will invest the resources necessary to meet system requirements developed by politicians?  The failure to build meaningful use upon previous ground work is concerning.

          

Are ONC’s Meaningful Use Requirements Workable? originally appeared on Law Blog 2.0 on July 30, 2009.