The typical use case of an HIE under a federated exchange model transaction involves:

• Initiation of a request to the HIE service to determine if a person has relevant medical information within the HIE;
• A response is returned to the requesting organization, which would request to receive the relevant data.
• The HIE service would verify that the requesting organization is authorized, authenticated, and has access privileges to the information and that the person has provided consent for transmission of the given information;
• The approval along with supporting metadata is transmitted to the supplying organization who has the relevant information; and
• The disclosing organization would supply the information as required by the underlying data sharing or HIE participation agreements.

Both HIEs and networks of HIE (basically the NHIN) must be able establishing a baseline of trust among participants, typically, this trust includes–

• Processes to ensure the integrity of patient data;
• Verifiability of data after transforming, storing and/or sending (e.g. checksum, error checking, etc.);
• Verification that the data source and data content are true; and
• Organization the HIE or the NHIN can define standardized data values and a protocol format for sharing medical data.

Implementation usually requires:

• A data sharing agreements and policies to enable information sharing and make system usable;
• An enterprise master patient index (eMPI) which serves as a record locator; and
• A balancing of data standardization (normalization) and physician freedom to have clinical control of the medical record while being efficient in their treatment of patients.[ii]

I have excerpted privacy and security related covenants from a document entitled Overview: Data Use and Reciprocal Support (DURSA) Provisions Overview, dated November 20, 2009, which provides a summary of key features of a comprehensive agreement that governs the exchange of health data across a diverse set of public and private entities.  This agreement – the Data Use and Reciprocal Support Agreement (“DURSA”) requires that:

• To the extent that each Participant has existing privacy and security obligations under applicable law (e.g. HIPAA or other state or federal privacy and security statutes and regulations), the Participant is required to continue complying with these obligations.  Participants, which are neither HIPAA covered entities, HIPAA business associates nor governmental agencies, are obligated to comply with specified HIPAA Privacy and Security Rules as a contractual standard of performance.
• It is the responsibility of the responding Participant – the one disclosing the data – to make sure that it has met all legal requirements before disclosing the data, including, but not limited to, obtaining any consent or authorization that is required by law applicable to the responding Participant. This policy is essential for nationwide health information exchange given the number of different state laws, Federal statutes and local policies related to consent or authorization to exchange data for treatment purposes. To effectively enable the exchange of health information in a manner that protects the privacy, confidentiality and security of the data, the DURSA adopts the HIPAA Privacy and Security Rules as minimum requirements.
• Participants are required to promptly notify the NHIN Coordinating Committee and other impacted Participants of breaches which involve the unauthorized disclosure of data through the NHIN, take steps to mitigate the breach and implement corrective action plans to prevent such breaches from occurring in the future. Suspected breaches must be reported within one (1) hour of discovering information that leads the Participant to believe that a breach may have occurred.  As soon as reasonably practicable, but no later than twenty-four (24) hours, Participants must notify affected Participants and the NHIN Coordinating Committee This process is not intended to address any obligations for notifying consumers of breaches, but simply establishes an obligation for Participants to notify each other when breaches occur to facilitate an appropriate response.

(See Overview: Data Use and Reciprocal Support (DURSA) Provisions Overview, dated November 20, 2009)

HIE services typically includes:

• Patient identification and registry services within a directory structure;
• Consent management and enforcement of a user’s consent when collecting, storing, accessing, processing, and disclosing personal health information; and
• Information for the patient about the HIE at the point of care and a business process to obtain consent that will be used  for future exchange of data until changed by the individual.

The CONNECT framework is designed to offer similar services for the NHIN.  CONNECT is designed to implement privacy and security controls defined in the NHIN services, and when implemented and combined with the NHIN operating procedures and the DURSA, it allows organizations to participate in the “web of trust” that enables the secure exchange of interoperable health information among the participants of the NHIN.

Privacy and security laws do not directly cover NHIN in the sense NHIN is really a collaboration of many organizations who elect to participate in the network.  Several different types of entities participate in the NHIN. There are HIPAA “covered entities”, such as providers, there are the HIPAA-defined “business associates” of those covered entities, and there are non-covered entities which are not currently required to comply with HIPAA rules.

The NHIN is more like the Internet than a traditional health information system found within a hospital.  NHIN while not a covered entity, NHIN has a similar threat profile.  Similar to an HIE, the Data Use and Reciprocal Support Agreements (DURSA) permit network participants to contract the specific terms under which they will exchange information, including addressing privacy and security needs of each NHIE amongst themselves.  The responsibility for security, including compliance with state and federal laws, including HIPAA, rests with the member organizations or the network nodes a hospital, physician’s office, etc.  Examples of common DURSA contracts/agreements are listed in the table below.

The typical Connect implementation involves the use of a server based PKI and the NHIN NHIE service registry which define and secure the NHIN core backbone.  Connect services include-

• The messaging platform and authorization framework to implement security and privacy controls to address the known threats for Web services implementations of service-oriented-architectures;
• The audit log query service is designed to meet the requirements for HIPAA disclosure accounting;
• The consumer preferences profile allowomg consumers to express their preferences for whether or not to share their information on the NHIN and for more granular control over access to their private information. The CONNECT policy engine enforces those preferences in the runtime environment to insure that the access policies of the organization and the preferences of the consumer are honored in the decision to release health information in response to a request from the NHIN

In a separate draft publication ONC has detailed use cases on how to obtain, modify, and detail a patient’s consent to access his/her medical record.

If this all seems to daunting, a less ambitious project was recently announced by ONC called NHIN Direct.  The NHIN Direct project is focused on smaller providers who are unable to implement the Connect solution, and/or put in place an appropriate DURSA.  According to ONC- “NHIN Direct is intended to solve simple direct secure electronic transport supporting health information exchange currently being handled via paper or portal communication following existing trust models.”

Transactions that would fall within the scope of NHIN Direct would be those transactions involving the communication of pre-existing information typically transferred via fax, courier, mail or clipboard, or in some cases, via a patient/physician portal.  The transactions must be “push transactions” where patient identity is known and consent and legal authorization exists for the information transfer. (See http://nhindirect.org/User+Stories).[iii]

Additional Information – Data Sharing Agreements

Sample DURSA Business Associate Addendum

Sample Health Information Exchange Agreement

AMENDED AND RESTATED CLINICAL OUTCOMES ASSESSMENT PROGRAM HEALTH CARE PROVIDER INFORMATION SHARING AGREEMENT

ONC NHIN Draft Policies

2010 NHIN Final Production Specifications
The following specifications have been provisionally approved by the NHIN Technical Committee. This approval is subject to the validation of the NHIN reference implementation.

• Access Consent Policies Production Specification – v1.0 [PDF - 176 KB]
  
• Authorization Framework Production Specification v2.0 [PDF - 256 KB]
  
• Query for Documents Production Specification v2.0 [PDF - 212 KB]
  
• Retrieve Documents Production Specification v2.0 [PDF - 178 KB]
  
• Health Information Event Messaging Production Specification v2.0 [PDF - 152 KB]
  
• Messaging Platform Production Specification v2.0 [PDF - 248 KB]
  
• Patient Discovery Production Specification v1.0 [PDF - 214 KB]
  
• Web Services Registry Production Specification v2.0 [PDF - 378 KB]
  

Additional Information Available at the Following Sites:

• American Health Information Community (AHIC) http://www.hhs.gov/healthit/ahic.html
• American Health Information Management Association (AHIMA) http://www.ahima.org/
• Certification Commission for Healthcare Information Technology (CCHIT) http://www.cchit.org
• Commission on Systemic Interoperability http://endingthedocumentgame.gov
• Healthcare Information and Management Systems Society (HIMSS) http://himss.org/ASP/index.asp
• HL7 United States http://www.hl7.org/
• International Health Terminology Standards Development Organization (IHTSDO) and SNOMED International http://www.ihtsdo.org/
• Office of the National Coordinator of Health Information Technology (ONCHIT) http://www.hhs.gov/healthit/

[ii] CONNECT has three primary components:

1. The Core Services Gateway implements the core NHIN services enabling such functions as locating patients at other health organizations within the NHIN, requesting and receiving documents associated with the patient, and recording these transactions for subsequent auditing by patients and others. Other features include authenticating network participants, formulating and evaluating authorizations for the release of medical information, and honoring consumer preferences for sharing their information.
2. The Enterprise Service Component (ESC) provides default implementations of many critical enterprise components required to support electronic health information exchange, including a Master Patient Index (MPI), Document Registry and Repository, Authorization Policy Engine, Consumer Preferences Manager, HIPAA-compliant Audit Log.
3. The Universal Client Framework contains a set of applications that can be adapted to create an edge system, and be used as a reference system, and/or can be used as a test and demonstration system for the gateway solution.

[iii] The project has highlighted the following use cases for the NHIN project:
1. Primary care provider refers patient to specialist including summary care record
2. Primary care provider refers patient to hospital including summary care record
3. Specialist sends summary care information back to referring provider
4. Hospital sends discharge information to referring provider
5. Laboratory sends lab results to ordering provider
6. Providers without a fully certified EHR send and receive data
7. Primary care provider sends patient immunization data to public health
8. Pharmacist sends medication therapy management consult to primary care provider
9. Provider sends patient health information to the patient
10. Provider sends a clinical summary of an office visit to the patient
11. Hospital sends a clinical summary at discharge to the patient
12. Provider or hospital reports quality measures to CMS
13. Provider or hospital reports quality measures to State
14. Laboratory reports test results for some specific conditions to public health
15. State public health agency reports public health data to Centers for Disease Control
16. Provider reports to the State
17. Hospitals reporting to the State

Related Blogs

• Great Visualizers: Stefanie Posavec | Information Is Beautiful
• The anatomy of HIPAA.: An article from: Arkansas Business
• ‘This is a patient’s bill of rights on steroids’ | RedState
• Patient input in their treatment should be valued by doctors | KevinMD.com

          

HIE and NHIN Implementation Issues: (a) Data Sharing Agreements, (b) the Master Patient Index, (c) Data Standardization, (d) Consent Requirements, and (e) Duties of Network Participants originally appeared on Law Blog 2.0 on March 25, 2010.

http://docs.house.gov/rules/hr4872/111_hr4872_amndsub.pdf.  This Bill was agreed to by both the Senate and House and will be signed into law by the President this week.[i] I am, probably like most Americans a little worried/ curious how things will evolved form here.  Last winter when my wife had to wait in line for six hours at the Virginia Department of Public Health on two separate occasions, for our twin daughters 14 months old to receive their H1N1 vaccination,  causes me to wonder what exactly health reform will mean for the quality and efficient  health care.  There are hidden costs of waiting in line for health care, these costs may be more then some of the more sick can endure.  Health care is partly a supply and demand problem — with something like universal health care some thought should be given to where and how we can train many new caregivers at a reasonable cost.  Forty-five thousand dollars per year for a physician (4 years), or for a physician assistant (2 years) is a large sum of money.

In summary the Bill provides:

• Under the Bill Insurance companies would be prohibited from: (1) denying coverage based on pre-existing medical conditions; (2) rescinding coverage to members who get sick; (2) creating restrictions on coverage such as lifetime and annual;  (4) making excessive profits; and (5) restricting preventative services and immunizations.

• By 2014 Americans would be required to have health insurance.  Uninsured individuals would be penalized with a tax of $95 in 2014, $325 in 2015 and $695 in 2016 and beyond.   More significantly employers who do not provide “affordable” coverage would be fined $3,000 per worker.

• New tax credits would be available under the Bill, for those whose income is below 400 percent of the Federal Poverty Level, a typical subsidy would be $6,000 per year.  Families with an annual income of as much as $88,000 a year could receive tax credits.

• All individuals, 16 million Americans by 2019, earning less than 133 percent of Federal Poverty Level would receive insurance through Medicaid.

It remains uncertain whether provisions requiring health coverage for all individuals will hold up to Constitutional review.  Review by the Supreme Court is almost a certainty, if the Bill becomes law.

Links of interest include the:

• Amendment to the Reconciliation Bill:  http://docs.house.gov/rules/hr4872/111_managers_hr4872.pdf
• Summary of the Reconciliation Bill: http://www.rules.house.gov/111_hr4872_secbysec.html
• Summary of the Amendment to the Reconciliation Bill: http://www.rules.house.gov/amendment_details.aspx?NewsID=4611

The Reconciliation Bill was passed by the House last night and seeks to modify the Senate Bill that will be signed into law shortly.  It contains the compromise positions required by the House for them to pass the Senate Bill.  The Reconciliation bill is not yet law and will be considered by the Senate this week.  The Kaiser Family Foundation provides a summary of the legislation as well as comparisons of the various proposals at http://kff.org/healthreform/sidebyside.cfm.

Health Reform Survey

Related Blogs

• Healthcare Reform Bill Summary
• Balloon Juice » Blog Archive » Reconciliation vote starts
• TotallyTarget.com » Free St Ives Travel Size Products w/New Qs
• Target Deals: 3/21-3/27/10
• Summary of today’s #cashgordon social media silliness

          

Health Reform Good For the American People? originally appeared on Law Blog 2.0 on March 23, 2010.

First, the SP 800-128 includes a sample of the data elements that should be tracked for a change request:

• Date Prepared;
• Title of Change Request;
• Change Initiator/Project Manager;
• Change Description;
• Change Justification;
• Urgency of Change: {Scheduled/Urgent/Unscheduled};
• Personnel involved with the Change;
• Expected Security Impact of Change;
• Expected Functional Impact of Change;
• Expected Impact of Not Doing Change;
• Potential Interface/Integration Issues;
• Required Changes to Existing Applications;
• Project work plan including change implementation date, deliverables, and back-out plan; and
• Funding Required Implementing Change.

Appendix F to SP 800-128, entitled BEST PRACTICES FOR ESTABLISHING SECURE CONFIGURATIONS provides very specific industry guidance on good security configuration management practices. (the following is largely a reproduction of Appendix F, however, I have summarized what I consider to be the most significant issues and removed duplicative references to some NIST Publications.  Some personal commentary appears in red below.

Use Standards for Secure Configuration Settings. Organizations should consider available standards as the basis for establishing secure configuration settings. A source for information on configuration settings is the National Checklist Program.

• NIST SP 800-68: Guide to Securing Microsoft Windows XP Systems for IT Professionals;
• NIST SP 800-69: Guidance for Securing Microsoft Windows XP Home Edition: A NIST Security Configuration Checklist; and
• NIST SP 800-70: National Checklist Program for IT Products-Guidelines for Checklist Users and Developers.

Centralize Policy and Standards for Configuration Settings. Where possible and appropriate, secure configurations should be developed and implemented in a top-down approach to ensure consistency across the organization. An example is the implementation of the group policy functionality, which can be used to distribute secure configuration policy in a centralized manner throughout established domains.

Tailor Secure Configurations According to System/Component Function and Role. Secure configuration settings should be tailored to the system component’s function. For example, a server acting as a Windows domain controller may require stricter auditing requirements (e.g., auditing successful and unsuccessful account logons) than a file server. A public access Web server in a DMZ may require that fewer services are running than in a Web server behind an organization’s firewall supporting an intranet.

• NIST SP 800-41: Guidelines on Firewalls and Firewall Policy (Consumer grade network routerts and wireless routers can be significant improved by using DD-WRT.  “DD-WRT is a Linux based alternative OpenSource firmware suitable for a great variety of WLAN routers and embedded systems.” (See http://www.dd-wrt.com/site/index.) ;
• NIST SP 800-44: Guidelines on Securing Public Web Servers;
• NIST SP 800-45: Guidelines on Electronic Mail Security;
• NIST SP 800-48: Guide to Securing Legacy IEEE 802.11 Wireless Networks (I would avoid having a wireless network connected to a e-PHI system if possible);
• NIST SP 800-52: Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations; (Mandatory TLS encryption is still difficult to implement, most organizations are not in a position to support this functionality on their email solution);
• NIST SP 800-95: Guide to Secure Web Services;
• NIST SP 800-123: Guide to General Server Security; and
• NIST SP 800-124: Guidelines on Cell Phone and PDA Security. (Consumer grade cell phones, PDAs, and blackberries have a number of security configurations available (e.g. timeout, password protection, etc.) that can help to secure these devices).

Eliminate Unnecessary Ports, Services, and Protocols (Least Functionality). Devices should be configured to allow only the necessary ports, protocols, and services in accordance with functional needs and the risk tolerance in the organization. Open ports and available protocols and services are an inviting target for attackers, especially if there are known vulnerabilities associated with a given port, protocol, or service. Sources such as the NIST National Vulnerability Database (NVD) are available for highlighting vulnerabilities in various system components.

Limit the Use of Remote Connections. While connecting remotely to information systems allows more flexibility in how users and system administrators accomplish their work, it also opens an avenue of attack popular with hackers. Use of remote connections should be limited to only those absolutely necessary for mission accomplishment.

• NIST SP 800-46: Guide to Enterprise Telework and Remote Access Security;
• NIST SP 800-47: Security Guide for Interconnecting Information Technology Systems; and
• NIST SP 800-77: Guide to IPsec VPNs.

Develop Strong Password Policies. Passwords are a common mechanism for authenticating the identity of users and if they are poorly implemented or used, an attacker can undermine the best security configuration. Organizations should stipulate password policies and related requirements with the strength appropriate for protecting access to the organization’s assets.

Implement Endpoint Protection Platforms (EPPs). Personal computers are a fundamental part of any organization’s information system. They are an important source of connecting end users to networks and information systems, and are also a major source of vulnerabilities and a frequent target of attackers looking to penetrate a network. User behavior is difficult to control and hard to predict, and user actions, whether it is clicking on a link that executes malware or changing a security setting to improve the usability of their PC, frequently allow exploitation of vulnerabilities. Commercial vendors offer a variety of products to improve security at the “endpoints” of a network. These EPPs include:

• Anti-malware. Anti-malware applications should be a part of the standard secure configuration for system components. Anti-malware software employs a wide range of signatures and detection schemes, automatically updates signatures, disallows modification by users, run scans on a frequently scheduled basis, have an auto-protect feature set to scan automatically when a user action is performed (e.g., opening or copying a file), and may provide protection from zero-day attacks. For platforms for which anti-malware software is not available, other forms of anti-malware such as rootkit detectors may be employed.
• Personal Firewalls. Personal firewalls provide a wide range of protection for host machines including restriction on ports and services, control against malicious programs executing on the host, control of removable devices such as USB devices, and auditing and logging capability.
• Host-based Intrusion Detection and Prevention System.  Host-based IDPS is an application that monitors the characteristics of a single host and the events occurring within that host to identify and stop suspicious activity.
• Restrict the use of mobile code. Organizations should be cautious in allowing the use of “mobile code” such as ActiveX, Java, and JavaScript. An attacker can easily attach a script to a URL in a Web page or email that, when clicked, will execute malicious code within the computer’s browser.

NIST SP 800-28: Guidelines on Active Content and Mobile Code.

Use Cryptography.  In many systems, especially those processing, storing, or transmitting information that is moderate impact or higher for confidentiality, cryptography should be considered as a part of an information system’s secure configuration. There are a variety of places to implement cryptography to protect data including individual file encryption, full disk encryption, Virtual Private Network connections, etc.

NIST SP 800-111: Guide to Storage Encryption Technologies for End User Devices.

Develop a Patch Management Process. A robust patch management process is important in reducing vulnerabilities in an information system. As patches greatly impact the secure configuration of an information system, the patch management process should be integrated into SCM at a number of points within the four SCM phases including:

• Performing security impact analysis of patches;
• Testing and approving patches as part of the configuration change control process;
• Updating baseline configurations to include current patch level;
• Assessing patches to ensure they were implemented properly; and
• Monitoring systems/components for current patch status.

NIST SP 800-40: Creating a Patch and Vulnerability Program.

Control Software Installation. The installation of software is a point where many vulnerabilities are introduced into an organization’s information system. Malware or insecure software can give attackers easy accessto an organization’s otherwise tightly protected network. Although the simplest approach is to lock down computers and manage software installation centrally, this is not always a viable option in many organizations. Other methods for controlling the installation of software include:

• Whitelisting – All software is checked against a list approved by the organization;
• Checksums – All software is checked to make sure the code has not changed;
• Certificate – Only software with signed certificates from a trusted vendor is used;
• Path or domain – Only software within a directory or domain can be installed; and
• File extension – Software with certain file extensions such as .bat cannot be installed.

Related Blogs

• The Internet Public Libraray With a Useful Guide to Photo Sharing …
• PREPRINT: Free Access: “Use of Web Resources in the Journal …
• Israel's Policy and the idea of A One State solution
• Researchers Map Multi-Network Cybercrime Infrastructure — Krebs on …
• Alan Taub Elected Vice Chair of NIST Advisory Group | Japanese …

          

NIST announced the publication of Initial Public Draft Special Publication 800-128, Guide for Security Configuration Management of Information Systems. originally appeared on Law Blog 2.0 on March 19, 2010.

Identity Theft and Consumer Protect Laws.

One of the most common (and high risk) user installed software found on the enterprise desktop computer is P2P[i] file-sharing software.  This software can be detected with networking scanning software like Nessus.[ii]

Unlike, other software, P2P file-sharing software is very effective at circumventing an organization’s security perimeter.  In most organizations measures in-place to prevent users from installing software are easily circumvented: (1) by installing and running the device from a USB key, (2) using the local Administrator account to install the software because the local Administrator account has not been set after the last re-image or the local administrator account password is known to users, or (3) IT installs the software at the request of a user.  Recently, the Department of Health and Human Services (“HHS “)has been very proactive in getting the message out that portable media, laptops, and other similar devices that contain electronic protected health information (e-PHI) must be encrypted.  However, despite numerous alleged disclosures of e-PHI on P2P networks, HHS is failing to inform patients, covered entities, and business associates of covered entities about the risks of peer-to-peer (P2P) file sharing and the inadvertent sharing of documents containing e-PHI.

Last Summer P2P programs reportedly inadvertently shared information about presidential motorcade routes, a Secret Service safe house for former first lady Laura Bush, and personal information of more than 220,000 soldiers and hospital patients.[iii]

In February of 2009, a researcher at Dartmouth College using four P2P networks — Gnutella, FastTrack, Aries and eDonkey —collected 3,328 files.  The researcher located 161 unique files contained sensitive information that could be used to commit medical or financial identity theft. (See Johnson, M. Eric, Data Hemorrhages in the Health-Care Sector, Center for Digital Strategies, Tuck School of Business, Dartmouth College, Hanover NH 03755)(available at http://mba.tuck.dartmouth.edu/digital/Research/ResearchProjects/JohnsonHemorrhagesFC09Proceedingd.pdf)(see also http://www.wired.com/threatlevel/2009/03/p2p-networks-le/).

On March 5, 2010, a research paper entitled The Inadvertent Disclosure of Personal Health Information Through Peer-To-Peer File Sharing Programs confirmed the Dartmouth Study.  This study found that:

Approximately 0.4% of Canadian IP addresses had PHI, as did 0.5% of US IP addresses. There was more disclosure of financial information, at 1.7% of Canadian IP addresses and 4.7% of US IP addresses. An analysis of search terms used in these file sharing networks showed that a small percentage of the terms would return PHI and PFI files (ie, there are people successfully searching for PFI and PHI on the peer-to-peer file sharing networks).

(See J Am Med Inform Assoc 2010;17:148e158. doi:10.1136/jamia.2009.000232)(article available at http://jamia.bmj.com/content/17/2/148.short).  Additional examples and case studies of various types of disclosures are available within a web only appendix available at http://jamia.bmj.com/content/17/2/148/suppl/DC1.

Legislators have proposed at least one Bill HR 1319 (December 9, 2009) to limit the undisclosed sharing of files without a user’s consent. (HR 1319 is entitled “AN ACT To prevent the inadvertent disclosure of information on a computer through certain ‘‘peer-to-peer’’ file sharing programs without first providing notice and obtaining consent from an owner or authorized user of the computer” and is available at http://www.govtrack.us/congress/bill.xpd?bill=h111-1319).  With the prospect of legislation requiring P2P software vendors to educate users, control network content, and require other family friendly features – steps are being taken by mainstream P2P file sharing companies to inform users how to properly configure their software.  In addition, some companies have re-designed their products with default configurations that may in some circumstances share less information of a sensitive nature.  (See http://www.limewire.com/legal/safety).

The FTC has been proactive about informing consumers and companies of the risks of P2P file-sharing to their personal information.  In late February (2010) the FTC sent out warning letters to more than 100 companies highlighting concerns about personal information of consumers and/or employees being found on file-sharing networks. The FTC requested that aforementioned companies review internal security procedures and the security procedures of their third party service providers and/or business associates.  The FTC also requested that companies identify affected individuals and assess whether to notify them of the possible risks to their personal information pursuant to applicable state and federal data security breach notification laws (See Widespread Data Breaches Uncovered by FTC Probe FTC Warns of Improper Release of Sensitive Consumer Data on P2P File-Sharing Networks, FTC Press Release dated February 22^nd, 2010, available at http://www.ftc.gov/opa/2010/02/p2palert.shtm).

The FTC also opened non-public investigations of other companies whose customer or employee information has been exposed on P2P networks.  Significantly, the failure to prevent sensitive information from being shared on P2P networks potentially violates the Gramm-Leach-Bliley Act (which includes provisions to protect consumers’ personal financial information held by financial institutions) and/or Section 5 of the FTC Act.  Section 5 of the FTC Act prohibits “unfair methods of competition,” and was amended in 1938 to prohibit “unfair or deceptive acts or practices”.  Recent enforcement actions by the FTC relating to privacy and data security are available at www.ftc.gov/privacy/privacyinitiatives/ promises_enf.html.

The FTC recommends that Companies:

• Delete sensitive information you don’t need, and restrict where files with sensitive information can be saved;
• Minimize or eliminate the use of P2P file sharing programs on computers used to store or access sensitive information;
• Use appropriate file-naming conventions;
• Monitor your network to detect unapproved P2P file sharing programs;
• Block traffic associated with unapproved P2P file sharing programs at the network perimeter or network firewalls; and
• Train employees and others who access your network about the security risks inherent.

(See P2P FIlesharing , available at http://www.ftc.gov/bcp/edu/pubs/business/idtheft/bus64.pdf ; see also Protecting PERSONAL INFORMATION FEDERAL TRADE COMMISSION A Guide for Business, available at http://www.ftc.gov/bcp/edu/pubs/business/idtheft/bus69.pdf.)

Note, the FTC publication entitled Protecting PERSONAL INFORMATION FEDERAL TRADE COMMISSION A Guide for Business is well written and is available for republication.

To secure the personal information stored on one’s computer, the FTC recommends:

• Avoid Changes to Default Settings.  Any changes you make to the P2P software’s default settings during installation could put data at risk.  One could inadvertently share information on their hard drive: like your tax returns, email messages, medical records, photos, or other personal documents;

• System Maintenance. Some file-sharing programs may install malware that monitors a user’s computer use and then sends that data to third parties;

• Close your connection. In many instances, closing the file-sharing program window does not actually close your connection to the network. That allows file-sharing to continue and could increase your security risk; and

• Avoid Using an Administrator Account to run P2P Software. Administrator accounts permit installation of software.  Avoiding the use of an account that would permit the installation of software can help protect against malware.

(See P2P File-Sharing: Evaluate the Risks)

An example of a P2P file sharing policy is available at http://www.k-state.edu/policies/ppm/3490.html.

Related Links

http://www.ftc.gov/infosecurity

http://www.OnGuardOnline.gov

http://www.sans.org/top20

http://www.us-cert.gov

Comparison of Feature of Populat P2P Clients

Not all distributed file sharing protocols are necessarily bad, for example Bittorent, another popular file sharing protocol, is invaluable in distributing large files.  The installation disks for the open source operating system Linux may be as large as 4 gigabytes multiple users downloading this large file could limit the bandwidth of a major university without protocols like Bittorent.  This protocol makes many small data requests over different TCP connections to different machines, while classic downloading is made via a single TCP connection to a single machine.  Many P2P file sharing software packages use a simple http connection for downloading data from a host computer once a host is located with the user’s desired content.  Unlike other P2P software, someone must “seed” a Bittorent download with a small file called a “torrent” that is used as a pointer for the file but the host of the torrent does not serve as the primary source of the data being downloaded by the end user.

[ii] (See http://www.nessus.org/whitepapers/reliability_and_uniqueness_of_nessus.pdf.)

[iii] (See http://www.washingtonpost.com/wp-dyn/content/article/2009/07/29/AR2009072902273_pf.html; http://voices.washingtonpost.com/securityfix/2009/07/report_locations_of_all_us_nuc.html; http://www.computerworld.com/s/article/9136053/Details_on_presidential_motorcades_safe_house_for_First_Family_leak_via_P2P?taxonomyId=17; http://www.smh.com.au/technology/technology-news/topsecret-obama-safe-house-leaked-on-limewire-20090730-e267.html; http://www.nextgov.com/nextgov/ng_20090729_2566.php?oref=topnews; http://www.nextgov.com/nextgov/ng_20090729_3555.php?oref=topnews; http://www.reuters.com/article/technologyNews/idUSTRE56S4T420090729; http://www.internetnews.com/government/article.php/3832556/Data+of+Soldiers+Hospital+Patients+Found+on+P2P.htm.)

Related Blogs

• Legal Information Institute: Sunlight Foundation Proposes Public …
• Wow! Construction Complete! C-SPAN Puts Complete Archive (23 years …
• Privacy Lives » Blog Archive » Federal News Radio: FTC looks at …
• File-Sharing and Link Sites Declared Legal in Spain | TorrentFreak
• Unfinished business « Though Cowards Flinch

          

P2P Leaks of Protected Health Information –HIPAA Covered Entities and Business Associates Should Have a P2P Software Policy Either Prohibiting the Use of P2P Software or Instructing Users on the Safe Use of P2P Software. originally appeared on Law Blog 2.0 on March 16, 2010.

HHS

On March 15, 2010, ONC completed the announcement of State Health Information (State HIE) Exchange Cooperative Agreement Program awardees.  The first announcement of awards were on February 12th, 2010.   These awards are meant as seed money for State HIE’s which are expected to reach financial independent within 2 to 4 years.  The Awardees will be evaluated on various criteria over a four year period.  The criteria are detailed in http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_10741_888442_0_0_18/FOA_State%20Health%20Information%20Exchange%20Cooperative%20Agreement%20Program_Sept3_updated%20funding%20formula.doc.  A PDF of this same document is available here: FOA_State Health Information Exchange Cooperative Agreement Program_Sept3_updated funding formula.  Generally, HIEs are intended to transmit healthcare information electronically across organizations within a region, community or hospital system.  HIE generally allow for the movement of clinical information among disparate health systems.  Various gateways and interface utilities are used to translate data from disparate information systems.

The parameters of the program include:

• The Health Information Technology for Economic and Clinical Health (HITECH) Act, enacted as part of the American Recovery and Reinvestment Act of 2009 (ARRA), amends Title XXX of the Public Health Service Act (PHSA) by adding Section 3013, State Grants to Promote Health Information Technology. Section 3013 establishes the State Health Information Exchange Cooperative Agreement Program;
• The State Health Information Exchange (State HIE) Cooperative Agreement Program awards cooperative agreements to states, eligible territories, and qualified State Designated Entities (SDEs) to develop and advance mechanisms for information sharing across the health care system, including establishing health information exchange (HIE) capacity among health care providers and hospitals in their jurisdiction, ultimately enabling exchange across states;
• The funding instrument that the State HIE Program has chosen to use in administering the awards is a cooperative agreement.  A cooperative agreement is a partnership between the grant recipient and the Federal government, when the Federal government has a substantial stake in the outcomes or operations of the program.  The State HIE cooperative agreements have a four-year performance period and recipients will be required to match a portion of grant awards beginning in the second year of the award, 2011; and
• Under this program, $548 million has been awarded to support efforts to facilitate and expand the secure, electronic movement and use of health information among organizations according to nationally recognized standards. The governance, policy and technical infrastructure supported through this program will enable standards-based HIE and a high performance health care system.  HIE is fundamental to realizing the promise of meaningful use of EHRs and HIT that leads to improved quality, efficiency and safety of health care.

(See HealthIT.hhs.gov)

States must also:

• Develop and implement up-to-date privacy and security requirements for HIE with and across state borders;
• Develop state-level 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.

The State HIE Cooperative Agreement Program funds states’ efforts to rapidly build capacity for exchanging health information across the health care system both within and across states. Awardees are responsible for increasing connectivity and enabling patient-centric information flow to improve the quality and efficiency of care. Key to this is the continual evolution and advancement of necessary governance, policies, technical services, business operations, and financing mechanisms for HIE over each state, territory, and SDE’s four-year performance period.

Grantees in the second round of awards (announced March 15, 2010):

• State of Alaska
• Department of Public Health, State of CT
• Agency of Health Care Administration (FL)
• Iowa Department of Public Health
• Idaho Health Data Exchange
• Indiana Health Information Technology, Inc.
• Louisiana Health Care Quality Forum
• The Maryland Department of Health and Mental Hygiene
• State of Mississippi
• HealthShare Montana
• State of North Dakota, Information Technology Department
• Nebraska Department of Administrative Services
• New Jersey Health Care Facilities Financing Authority
• South Carolina Department of Health & Human Services
• South Dakota Department of Health
• Texas Health and Human Services Commission

Grantees in the first round of awards (announced February 12, 2010):

• Rhode Island Quality Institute
• State of Oregon
• Georgia Department of Community Health
• Kansas Health Information Exchange Project
• Cabinet for Health and Family Services (KY)
• Missouri Depart of Social Services
• Colorado Regional Health Information Organization
• Health Care Authority (Washington)
• Governor’s Office of Health Care Reform Commonwealth of PA
• Virginia Department of Health
• State of Maine/Governor’s Office of Health Policy & Finance
• The Hawaii Health Information Exchange
• Wisconsin Department of Health and Family Services
• Government of the District of Columbia
• Minnesota Department of Health
• Virgin Islands Department of Health
• Oticina del Gobernador La Fortaeza (PR)
• Illinois Department of Healthcare and Family Services
• New Hampshire Department of Health and Human Services
• Alabama Medicaid Agency
• California Health and Human Services Agency
• Utah Department of Health
• Vermont Department of Human Services
• Massachusetts Technology Park Corporation
• Lovelace Clinic Foundation (New Mexico)
• State of Tennessee
• North Carolina Department of State Treasurer
• West Virginia Department of Health and Human Resources
• Arkansas Dept of Finance and Administration
• Delaware Health Information Network
• Michigan Department of Health
• New York eHealth Collaborative, Inc.
• Oklahoma Health Care Authority
• Pacific Ecommerce Development Corporation (American Samoa)
• Ohio Health Information Partnership, LLC
• Arizona Governor’s Office of Economic Recovery
• Nevada Department of Health and Human Services
• Office of the Governor (Guam)
• Commonwealth of the NMI, Department of Public Health
• Office of the Governor (WY)

(see http://healthit.hhs.gov/portal/server.pt?open=512&objID=1488&parentname=CommunityPage&parentid=2&mode=2&in_hi_userid=10741&cached=true).

Related Blogs

          

ONC 2nd Annoucement for HIE Grants and a Review of Program Requirements originally appeared on Law Blog 2.0 on March 16, 2010.

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.

Update-

Under the HITECH breach notification requirements, covered entities must notify HHS of all reportable breaches.  HHS recently released a list of breaches, including the covered entity, the business associate, number of individuals affected, and the location of the information lost.  More than 35 HIPAA covered entities have reported breaches involving more than 500 individuals’ PHI since September 2009.  The theft/loss of laptops, desktop and portable media by far represent the majority of the security breaches reported thus far.  A summary of breaches reported thus far appears below.

Reported Breaches of PHI

Older Story – October 12, 2009 — Content of the Notice to the Secretary of HHS for a Reportable Security Breach

The Secretary has delayed enforcement of the Security Breach Rules to give covered entities and business associates a reasonable amount of time to come into compliance.  However, in anticipation of covered entities’ new reporting obligations, HHS on October 7th, released an online form (OMB No. 0990-0346) that appears to be the exclusive mechanism by which a covered entity can provide the required notice to the Secretary in the event of a security breach. (The form is available at http://transparency.cit.nih.gov/breach/index.cfm).  The form is intended only for security breach submissions by covered entities to the Secretary; breaches involving business associates must be reported directly to the Secretary by the affected covered entity and not by the business associate.

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.

Related Blogs

          

HHS Breach Notifications originally appeared on Law Blog 2.0 on March 1, 2010.

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).

Related Blogs

• Legal Information Institute: Sunlight Foundation Proposes Public …
• Information About Usual Swine Flu Symptoms | Pig Flu Pandemic …
• PHP Development India – maglev08.com
• elearnspace › Social Networks and Learning: Research/Doctoral Seminar
• Club Troppo » What a free computer might do for a kid's education …
• Book preview: PHP 5 E-commerce Development « Eirik Hoem's Blog
• Commtouch's New Open-Source Email Security Technology Featured at …
• Cybersecurity Technologies a Government Priority | The New New …
• Featured Job- Cyber Security Engineer with Booz Allen | The New …
• Stock Gumshoe Investigates: “$25 Cyber Security Doubler to Hit $50 …
• SEO Consult – Different content requires different styles of writing
• Programmers that… can't program. | Musings of an Anonymous Geek
• Nokia Research Centre Africa (NRC-Africa) research insights and …
• IP Osgoode » Building new models for innovation and R&D requires …
• The Alex Jones Show with Jason Bermas 1/3: Cybersecurity Act …
• UK Government Criticized For Frightening Climate Change Television …
• 50 Excellent Tutorials for Web Development Using CSS3 | Dzinepress
• Europe's economic recovery requires e-Skills
• Temporary Worker Program Could Threaten Immigration Reform …
• [Fix] Installation of Microsoft Office 2010 Requires MSXML Version …

          

Would you like to play a nice game of chess? originally appeared on Law Blog 2.0 on February 5, 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.