News

HIPAA, Meaningful Use and Risk Assessments

The Health Insurance Portability and Accountability Act (HIPAA) granted the Secretary of Health and Human Services the power to establish regulations for covered entities, including the information security policies of the entity.  An important aspect of the security regulations is regularly assessing risks to the entity’s information systems and infrastructure under section 164.308(a)(ii)(1) of the security regulations.  For those of you attempting to qualify for meaningful use incentives, risk assessments are a part of the core 15 metrics, making documented risk assessments mandatory.

The regulation specifically requires a covered entity to “conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity.”  Id.  This analytical process is helpful to the organization for several reasons.  First, doing an inventory of the information systems in use in the organization helps to categorize the extent of exposure of the organization to security threats.  Second, spending time on identifying known problems or vulnerabilities helps to clarify what should be budgeted for mitigating these problems.  Third, all risk assessment methodologies require an organization to balance the potential impact of the risk against available mitigations, and to choose a reasonable mitigation (one which costs less than the adjusted risk to the organization of loss).

However, the contents of a risk analysis are not defined with the security regulations, and such an analysis is not self-defining. There are a wide variety of analytical tools available today to help a provider assess risk to his business organization.  For example, the Centers for Medicaid and Medicare (CMS) created a risk assessment document that aids a provider in categorizing existing information systems, evaluating what risks exist to those systems, what mitigations are in place to reduce risk, and what risks remain that are sufficiently great that either additional mitigations are required or the business owner must accept them in order to continue to operate the system.   See Centers for Medicare & Medicaid Services (CMS) Information Security Business Risk Assessment Methodology, version 2.1 (May 11, 2005).

The CMS methodology also provides a guide to evaluating a specific risk by estimating the likelihood of the risk’s occurrence, and if left unmitigated, what impact the risk would have on business operations.  Those risks of a certain risk level or higher are those that require mitigation, helping an organization to prioritize which identified mitigations should be implemented first.  Id.  For example, risks to a payroll system, while critical to an organization’s efforts to operate, may not be critical as a health record system because the organization may only provide paychecks every other week, whereas the organization’s staff access the health record system for each patient visit on a daily or hourly basis.  Alternatively, the data in the payroll system may be at less risk overall (either because the system has fewer vulnerabilities or has less overall data) as compared to an electronic health record system.  Following this qualitative methodology helps organizations to reason through their relative risks and identify potential mitigations.

An alternative methodology follows a similar process, but instead utilizes estimates of the value of systems to the business, the likelihood that the risk will be realized, and a calculated value to the organization of potential mitigations of that risk for a particular period (for example, one year).  See Shon Harris, All-In-One CISSP, 73 (3rd ed. 2005) McGraw Hill/Osborne.  For example, if a the provider operates an electronic health record system, and the value of that system to the organization is 500,000, the provider could then identify various risks that exist to the data in that system and their relative likelihood of occurring, thus calculating the maximum value of an effective mitigation of that risk.  For example, if the risk identified is a computer virus, the analyst would take into consideration how many computer viruses are written for the system platform, what kind of damage a typical virus could do to the system, the history of virus infection of the systems in place in the organization, and other factors that impact virus infection.  In addition, the analyst would examine what efforts would be required to restore the infected information system to normal operations, and what data could be lost as a result to calculate the percentage of the system’s base value that would be affected by the risk.  Multiplying the base value of the system by the likelihood of the threat’s realization and by the scope of the risk’s impact on the base value gives an annualized risk value.  “Reasonable” mitigations of this risk should therefore cost less than this annualized risk value.

This quantitative approach is helpful for estimating risk and valuing mitigations, especially where the covered entity can identify the costs of mitigations (such as an anti-virus solution or disaster recovery system).  Something very unlikely to happen should usually not be mitigated with a very expensive solution.  Need help performing a risk assessment?  Give us a call for assistance.

HIPAA Security Regulations: Preparing for Disasters

The Health Insurance Portability and Accountability Act (HIPAA) 42 U.S.C. § 1320(d-1)(b) empowered the Secretary of Health and Human Services to promulgate standards for health care providers that “shall be consistent with the objective of reducing the administrative costs of providing and paying for health care.” Under Section 1320(d-2)(d), Congress empowered the Secretary to establish regulations for the security of health information. Under that grant of power, the Secretary promulgated rules on technical security in 45 C.F.R. section 164. Section 164.308(a)(7)(ii)(B), under the heading “disaster recovery plan,” requires that a covered entity establish “procedures to restore any loss of data.” The next section requires that the covered entity be able to operate its critical business processes during an emergency while still protecting the security of its protected health information.

Recovering from a disaster is a relatively complicated matter for most health care providers that have implemented a sufficiently robust system or network. This is because many health care providers regularly use a system for email, a system for managing appointments and billing, a different system for accounting for expenses and payroll, another system for managing health records, and other supporting systems (such as a Windows domain controller, file and print sharing, and other administrative servers). In some cases, rather than hosting these servers in-house, some providers have contracted with outside vendors that provide hosting services, or application service provider (ASP)-models for specific applications used by the provider.

The complexity of a recovery is increased by the nature and number of disasters that could occur to a provider’s information systems. For example, disasters include uncontrollable events such as hurricanes or floods, fires, and other natural disasters, but could also include technical failures such as a widespread and uncontrolled computer virus, or concerted terrorist activities that disrupt electrical power or harm human life.Each risk presents a different set of issues for a health care provider.

The other part of the recovery equation is what the organization’s expectation is for the time to recover from a system failure, and the relative tolerance of the organization for an outage. Some health care providers that operate all the time (like an emergency room) may not be able to tolerate long outages in order to provide care effectively for patients. Smaller providers may not be able to tolerate a long outage because of the financial impact on their practice. However, some systems may be less critical for recovery because their loss will not immediately stop a practice from seeing patients. Sorting out the complexity of recovery requires planning before a disaster hits.

Risk Analysis

Section 164.308(a)(1)(ii)(A)-(B) of the regulations require that all covered entities engage in regular risk analysis and risk planning and take action on this analysis to reduce risks to electronic protected health information. This analytical process is helpful in guiding the development of a disaster recovery plan because the risk analysis identifies all systems and data in use in the business organization, and helps to guide the organization to those systems that are sufficiently critical to require disaster recovery. Of those critical systems, some may require a more complicated or expensive disaster recovery plan in order to make them available more quickly in a disaster. For example, a payroll system, while critical to an organization’s efforts to operate, may not need to be available as quickly as a health record system because the organization may only provide paychecks every other week, whereas users access the health record system for each patient visit on a daily or hourly basis.

Developing A Recovery Plan

Once the organization has assessed its risks, the organization can develop a plan to manage those risks, which includes setting expectations for recovery time, describing particular disaster scenarios and the organization’s response to those scenarios, and identifying the resources needed to effectively recover from particular disasters. The organization’s plan can also identify when an organization will re-open for business following a disaster, whether or not the provider anticipates having to operate during a disaster (such as an emergency room staying open during a bioterrorism event), what the chain of command will be to respond to a disaster, and a communication plan for letting customers and staff know the status of the organization during and after an event.

The systems team can use this high level plan to examine in more detail the individual systems in play in the organization, and can evaluate what methods for recovery can be cost-effectively implemented to meet organizational requirements. For example, a weekly digital tape backup may be adequate for less critical systems that change little from week to week, whereas a real-time replication system may be required for highly critical data.

Testing and Making Plan Changes

Once a systems recovery plan has been developed, testing the plan is absolutely essential to ensure that the plan on paper will actually work in a real disaster. Practice is important for several reasons. First, systems staff that participate in testing will have a better idea of what to expect if a system failure occurs and will be more capable of responding to it. Second, testing helps to identify missing steps or pieces of the plan which can be addressed by the systems department before the next round of testing. Third, testing helps to identify how much training will be required for systems staff to be able to effectively respond to a failure. And finally, involving the end users in the testing cycles helps to set expectations appropriately should an actual disaster occur.

Keeping Up With System Changes

Doing a risk analysis, creating a recovery plan and testing the plan is most of the preparation for recovering from a disaster, but the systems that belong to the plan will change with time. All systems have patches and upgrades that need to be applied each year. In addition, organizations routinely add new systems, which may present new challenges for recovery planning. And, of course, personnel trained to perform recoveries will change with time, which will require that new staff that join the team be trained on system recovery. Do not underestimate the time and effort required to include additional systems in the testing and recovery plan.

Mitigating Disasters

Mitigations, like anti-virus software, automatic patching and control systems, firewalls and other border control devices, organizational policies on system account controls, robust permissions, and other mitigations are also absolutely essential to any disaster recovery process. As any systems veteran will tell you, avoiding a systems recovery is a systems department’s top priority. But mitigations are not an excuse for not having a disaster recovery plan, because no mitigation will be one hundred percent effective at preventing all system failures. Being prepared is always the best policy.

Need help getting your systems department prepared for disasters? Give us a call or send us an email.

Disaster Recovery Tabletop Exercises

Being able to recover from a major system failure is essential for most businesses today. The key to recovery, beyond implementing technology that supports disaster recovery, is to practice for disasters. That means periodically meeting with members of the organization to review the process an IT department will go through in order to, step by step, bring critical systems back from an uncontrolled virus attack, hurricane, or major hardware failure. The table top exercise described below is a relatively inexpensive way for an organization to discuss scenarios for systems recovery and identify issues in the current disaster recovery plan.

Pre-Meeting Setup
The exercise will be most effective if ahead of time a network diagram is created that provides the following details for the existing information system:

  • Local network geographic locations
  • Workstations, network switches, routers, servers, phone systems, and related equipment
  • Local and Wide area network connections, speeds, and carriers
  • Existing contracts for business continuity services
  • Matrix of existing IT staff and areas of expertise

Where possible, the network diagram should identify the high level systems in place in the organization, and degree of criticality of each system to continued business operations in the event of a disaster. The criticality of a system determines its priority in a recovery effort.

In addition, if the organization has a policy on systems availability or the operations of the organization during particular disasters, this policy should be available to staff in the meeting. This policy may identify disasters where the organization will continue to operate, the chain of command to respond to system disasters, and organizational expectations for recovery time objectives.

Meeting Content
With the network diagram, the IT/IS department should meet with its leadership and senior staff, and some representatives from the business units served by the information systems for approximately two hours. A member of the meeting should be designated to take notes on the course of the meeting, and a different member should be designated as moderator. Notes taken should be organized by disaster, and should identify which staff resources were available during each scenario, potential issues with recovery that were identified during the discussion, and open questions about configuration or recoverability.

Meeting Process
During the meeting, the following activities should take place:

1. A disaster scenario for discussion should be identified which will impact business operations.
2. Members of the team should identify what systems will be unavailable, the estimated length of the interruption to service, what IT resources will be available to respond to the disaster, and what impact the unavailable systems will have on continued business operations.
3. Members of the team should then work through the stated policy on Disaster Recovery for the organization, and identify the operational and technical steps required to recover the affected system or systems.
4. The group should come prepared to discuss experience with similar recoveries, and identify potential issues with performing a timely recovery of data. Relevant to the discussion is the fact that such a recovery has not been previously tested, or other known resource limitations on performing a recovery based on the scenario.
5. A member of the team should be identified as the note keeper for the discussion, and will be responsible for distributing notes of the meeting to all participants.

The process above should be repeated so that the group can address two to three disaster scenarios during the meeting. The total length of the meeting should be limited to two hours.

Post-Meeting Review
Following the meeting, a list of issues to be addressed should be created which should form the basis for a project or work plan. Where necessary, a budget for capital and/or ongoing expenses and resources should be developed based on the work plan. Research may need to be conducted on potential technical solutions or workarounds to identified issues during the exercise. In addition, the policies of the organization may need to be reviewed or modified in order to reflect actual practice in responding to disasters, or based on feedback from the team meeting. A technical testing plan may also be required based on the findings or proposed technical solutions to a systems failure.

A follow-up table top exercise should then be scheduled, based on the estimated time required to be able to appropriately address the issues identified in the previous table top exercise. Results from successive table top exercises can be used to demonstrate progress in preparedness for disasters.

For more details or information on how to conduct a table top exercise, see The National Institutes of Standards and Technology, special publication 800-84, section 4-1. Need help organizing or facilitating a table top exercise? Contact us for more information.

Second Life: Virtual World Meets Real World Copyright

Second Life, (click here for their main web site) an online virtual worlds system, has become the center of a recent copyright controversy involving, yes, virtual sex toys.  Apparently, there are not enough legitimate or inexpensive sex toys for all the denizens of Second Life, so some residents have elected to make knock-offs.  Just like the real-world controversies surrounding real-world goods made by companies like Tiffany and Louis Vuitton, Eros LLC has filed suit against the alleged infringers and Linden Labs, for housing and supporting the alleged knock-offs.  (See Wired Article)

Vicarious and contributory liability for copyright infringement are recognized by the courts as a cause of action under federal copyright law.  This kind of liability has been raised in recent years against the various music file sharing services that came and went, such as Napster (originally a file sharing service without any copyright licensing from the music companies that owned the music being shared), Gnutella, and Limewire.  Each of these services were held to be liable for the file sharing of their users, in part based on the notion of vicarious liability.  Cases prior to Napster et al. that addressed this kind of liability have developed along two lines: landlord-tenants where the landlord exercised no control over the leased premises, and dance-hall cases where the operator of the hall controlled the premises and obtained a direct financial benefit from the infringing performances.  Fonovisa, Inc. v. Cherry Auction, Inc., 76 F.3d 259 (9th Cir. 1996).  Under common law, landlords have not been held to have copyright liability where dance-hall operators have infringed the copyrights of others.

In Fonovisa, the defendant Cherry Auction operated a swap meet where it rented stalls to individuals who were selling unlicensed copies of bootlegged music owned by the plaintiff.    For the swap meet operator to be liable, the plaintiff had to prove that the operator controlled the marketplace and obtained a direct financial benefit from the sales of infringing works.  The Court sided with the plaintiff in Fonovisa, even though the defendant Cherry Auction did not receive a commission from the sales of the infringing materials.

Unlike the auction house in Fonovisa, Second Life does allow users access to their information system without making a payment.  Anyone can download a copy of the Second Life client, establish a username, and log in to the system.  Users start to rack up fees when they purchase virtual real estate within the system.  In addition, Linden Labs provides a virtual currency of Linden Dollars that allow for the exchange of virtual goods within the system.  Linden Dollars can be exchanged for U.S. dollars using the credit card or paypal account associated with your Second Life account.  As a result of this connection with the physical world, there are a number of users that make an actual living in Second Life producing virtual goods for their fellow Second Life denizens.  The last time I visited, about 17 million worth of linden dollars were exchanged into real dollars on the Linden Labs exchange system in a day.  Linden Labs is generating a significant amount of commerce in spite of the national recession.

According to Eros Products LLC, his SexGen products line has sold about 1 million (that’s U.S. dollars) of product within Second Life over the past five years.  (A copy of the Complaint is here).  Competition being fierce in the digital world, others have been making sex toys that look a lot like Eros’, with some likely being copied straight from the source and resold.  This is possible in Second Life because Second Life provides “builder” tools to its users.  Included in the toolkit are functions to allow for the upload of image files.  In addition, there are apparently tools available from other software makers that allow a Second Life user to copy images within the system.

Assuming that Eros Products LLC (and other plaintiffs that may join the suit should the court certify this as a class action) can prove that they are the valid owner of the copyrighted works, the question for the court is whether Linden Labs can meet the standard for contributory liability.  Linden Labs is a virtual landlord in the sense that users of Second Life pay an annual subscription in order to own virtual real estate within the virtual world.  The right to own this virtual property is limited by payment of the subscription.  You will note, however, that there are plenty of users that do not acquire any virtual real estate in Second Life – and for them, there is no fee to participate.

However, Linden Labs also charges fees for the conversion of Linden Dollars into U.S. Dollars through the Linden Exchange.  For infringers seeking to sell pirated works in the virtual world, the real benefit to them is the ability to take the proceeds of those sales and convert them back into hard currency for use in the real world.  Approximately 250 Linden Dollars are worth a U.S. Dollar (the trading in this currency fluctuates).  In order to convert Linden Dollars back to U.S. Dollars, Linden Labs charges a fee of 3.5% of the value of the transaction.  So, indirectly, Linden Labs benefits from the sale of infringing goods every time that the infringer converts his Linden Dollar proceeds to hard currency.

There is a question, however, of whether Linden Labs is merely a landlord who relinquished control to his infringing tenant.  Eros Products LLC claims that Linden Labs did exercise control over the activities of its users because all of the virtual worlds within Second Life are ultimately housed on servers controlled by Linden Labs.  Pl.’s Complaint at ¶ 127-128.  And furthermore, Linden Labs has ultimate control over its software that operates Second Life, and I suppose that Linden Labs could alter its software to prevent copyright infringement if it wished to do so (how, exactly, is another story).  Factually, however, I think this is going to be tough to prove.  Unlike Grokster, who marketed itself as the successor to Napster for those looking to willfully infringe on the copyrights of others, Linden Labs has not marketed itself as a safe haven for willful copyright infringers.  On the contrary, Linden Labs gave some thought to copyright in its license agreement, granting its users rights in the works they create in-world.  (See Terms of Service here at section 3.2)

Maryland LLC Formation: A Step By Step Guide

Maryland law provides for how to properly form a Maryland LLC.  Title 4A of the Maryland Corporations and Associations Act governs the formation and operation of limited liability companies (“LLC”) registered in Maryland. A Maryland LLC, when properly formed, provides limited liability for all members of the LLC for debts incurred by the LLC during normal operations. For example, if a member of a properly formed LLC opens a business credit card in the name of the LLC (and does not otherwise personally guarantee the debts of the LLC), the members are, generally, not personally liable for paying the credit card bill. This is also true for other contracts entered into between another party and the LLC. If the LLC or a person working for the LLC fails to perform under the contract, the LLC and not its members would be liable to the other party.

Owners of the LLC are referred to as “members” and own an interest in the LLC, generally proportionate to their capital contributions to the LLC. Members can contribute cash or equivalent to the LLC as a capital contribution, or members can contribute services in lieu of cash. For example, an accountant could contribute his time in his professional capacity in lieu of actually writing a check to the LLC, and the members could agree to value his time as a capital contribution to the entity. In addition, through the operating agreement, members of an LLC can agree to a different interest distribution from the proportion each invests in the LLC through capital contributions. This is common in smaller LLCs where the owners wish to remain equal owners, but one of the members contributes more money or time to the effort than the other members.

Step 1: Articles of Organizations
To register an LLC, a person files Articles of Organization with SDAT, and pays a registration fee. SDAT’s web site provides a form that can be used to file Articles of Organization. SDAT will accept Articles of Organization for filing by mail, in person, or by fax. SDAT charges additional fees for expedited registration of an LLC (and it also charges higher fees for faxed Articles).

By law, an LLC must have a name that is distinguishable from other entities already registered with the Maryland Department of Assessments and Taxation (“SDAT”), including names that have been reserved with SDAT, and assumed names of foreign entities. In addition, the name of the LLC must have the words “limited liability company,” “LLC,”, “L.L.C.,” “LC,” or “L.C.” within the name registered with SDAT. SDAT may refuse to register an LLC that does not comply with the naming requirements.

Step 2: Written Operating Agreement
Once SDAT has accepted the Articles of Organization, the LLC is formed under Maryland law. Title 4A does not require that an LLC’s members enter into a written operating agreement. However, a written agreement can help to organize the company and ensure that all of the members have similar expectations about how the company will be operated, who will provide what money or services to the company, and how decisions about the company will be made. If an operating agreement is not entered into by the members, Title 4A provides the legal defaults for rights and remedies of the members of the LLC.

Step 3: Register for Federal Employer Identification Number (FEIN)
Once the LLC is formed, it exists under Maryland law as a business entity. However, the LLC is also governed by the federal tax code, and is subject to taxation by the Internal Revenue Service. Generally, LLCs provide owners with pass-through taxation, which means that the profits of the LLC are distributed to each member of the LLC according to their proportionate share of the LLC, and the individual members then pay taxes on that profit as a part of their personal tax liability.

An LLC, however, must still report its earnings to the IRS on an appropriate tax form (usually form 1065 for partnerships), and will file Schedule K’s for each member indicating their proportionate share of the profit or loss of the LLC. To do so, the LLC must have an FEIN. To register for a FEIN requires completion and filing of form SS4, which is available on the IRS website.

Step 4: Open an LLC Bank Account
Most LLCs will require a way to receive money and make payments in order to operate. Members of the LLC should therefore establish a business banking account in the name of the LLC. Your bank will generally require that a member come in and provide a copy of the Articles of Organization and Operating Agreement of the LLC in order to establish an account.

Step 5: Establish an Accounting System
To operate, most LLCs will need to keep track of profits and expenses, along with capital contributions made by the members. Doing so by computer helps the LLC file its tax returns promptly, and also helps the members to manage the company’s finances. If none of the members are able to handle the financial bookkeeping, the LLC may consider hiring a bookkeeper or accountant to help the LLC in this area. Strong fiscal management is not required by law but is an essential ingredient to the success of any business.

Step 6: Establish Maryland Tax Accounts
The LLC may need to establish one or more tax accounts with the State of Maryland, including a sales and use tax account, an employer withholding account, an unemployment insurance account, and other accounts, depending on the nature of the LLC. In addition, each of these tax accounts requires regular reporting to the responsible state agency, and payment of tax monies on a regular basis determined by the responsible agency.

Maryland law also requires that LLC’s file a personal property tax return annually, and pay property taxes owed to the State and county in which the LLC is operated. A failure to do this may cause a forfeiture of the LLC’s charter, which essentially prevents the LLC from operating in Maryland or seeking redress in a Maryland court.

For more information, see the MarylandTaxes.com website.

Step 7: Establish a Principal Office
The LLC needs to operate from a physical location which is zoned by the county for the activity to be engaged in by the LLC.

Step 8: Other Licensing
If the LLC needs a business or trader’s license (generally for the sale of goods), the county in which the LLC does business will determine which Circuit Court Clerk will issue the license. Professionals, like accountants and lawyers, also must maintain a license to practice their profession which is issued by a state agency. See the Maryland Business and Occupations Article, and see the Maryland Judiciary website for more information.

There may be other considerations for forming an LLC in Maryland. If you have questions about the process, seek the advice of an attorney admitted to practice in your state, or contact us for Maryland legal questions.

Update on Meaningful Use and Contracting

What constitutes “meaningful use” of an electronic health record system has been updated by the Centers for Medicare and Medicaid (CMS) and the Department of Health and Human Services (HHS) in volume 75, number 144 of the Federal Register, page 44565, as of July 28, 2010.  These new definitions for stage 1 meaningful use are to go into effect as of September 27, 2010.  Under the original rule that was published at the end of 2009, there were a total of 25 standards that needed to be met by an EHR user to qualify as a meaningful user.  Under the final rule published July 28, the list has ben somewhat shortened, so that there are 15 “core” standards that must be met, under § 495.6(d), and an additional 5 standards from the list of 10 found in § 495.6(e) for those who qualify as eligible professionals under the regulation.  In parallel, eligible hospitals and critical access hospitals must meet the core standards in § 495.6(f), and 5 additional standards in § 495.6(g).

Under § 495.6(d), the following are the fifteen mandatory standards for eligible professionals:

(d)(1) use computerized provider order entry for medication orders for at least 30% of patients seen

(d)(2) implement drug-drug and drug-allergy interaction checking

(d)(3) main an up to date problem list

(d)(4) e-prescribing for at least 40% of all permissible prescriptions

(d)(5) maintain active medication list

(d)(6) maintain active allergy list

(d)(7) record particular demographics

(d)(8) record specific vital signs, including BMI and capability for growth charts

(d)(9) record smoking status

(d)(10) report ambulatory clinical quality measures to CMS or your State Medicaid EP (though the specifics are not provided here)

(d)(11) implement a clinical decision support rule

(d)(12) provide an electronic copy of health information to patient on request

(d)(13) provide patient clinical summaries at each patient visit

(d)(14) prove capability to exchange key clinical information electronically by performing at least one test of this capability

(d)(15) protect protected health information by complying with the risk assessment and risk reduction guidance in the HIPAA security rule, at 45 CFR § 164.308.

Eligible professionals also must pick and implement five of the following:

(e)(1) implement drug-formulary checking

(e)(2) incorporate lab test results into EHR

(e)(3) generate patient lists by specific conditions for quality improvement, research, outreach

(e)(4) patient preventive care reminders

(e)(5) provide patients with timely access to their health information

(e)(6) provide patients with patient-specific education resources

(e)(7) perform medication reconciliation when a patient is received from another setting of care

(e)(8) provide summary of care for patients referred or transitioned to another care setting

(e)(9) prove ability to exchange immunization data with an electronic registry

(e)(1) prove ability to exchange surveillance data with an electronic registry.

Some of the above are new, and some of the previous draft standards were dropped (such as a requirement to use electronic insurance eligibility or submit claims electroncially, which are typically under the purview of a practice management system, but not typical of an EHR).

Prospective EHR vendors should be able to show you how they will aid you in complying with these requirements, and a reputable EHR vendor should be willing to put its compliance efforts into its contract for sale and implementation.  If you already have an EHR vendor that you use today, now is the time to start the conversation on compliance with these requirements.  Expect more news on this very important regulatory topic soon.

Estate Planning for Small Businesses

Do you own your own business? Having a plan for your business is important to your business’ success in the market. Part of your planning should involve what will happen to your business when you retire or die, particularly if income from your business supports your loved ones. If you haven’t planned for business succession, or you haven’t reviewed your plan in a while, now might be a good time to talk with a professional for help.

There are several parts to consider when planning for business succession. First off, under Maryland law, people that die without a will leave their assets to family members based on the Intestate Succession Statute, which is codified in the Maryland Estates and Trust Code Ann. § 3-101 et seq. Generally, a married spouse with children will leave assets titled in their name, including business interests, to the surviving spouse and kids. If you are married, but have no kids and your parents have pre-deceased you, then your spouse will inherit those assets.

Now, individuals that die with a will are said to die “testate,” meaning that they have written down how they wish the things they own to be transferred to others at death. Some business owners have a will and plan which they have duly executed, which describes how they wish their assets, including the business, to be distributed. In many cases, the testator drafts his/her will to benefit a primary group of people or a single individual, such as a wife, child or other relative. It may be that the owner of a business wishes to leave the business to his wife or children.

However, there are a number of problems for an owner to simply leave his/her business interest with a spouse and/or children. For example, can your spouse or children operate the business in your stead? If you own the business with other people, do those other owners wish to continue the business with your relatives as an owner of the business? In addition, it may be that your family depends on the cash value of the business that you, as the owner, are able to draw out of the business (either by salary or by profit distributions). If those family members cannot effectively work for the business to generate income or maintain the profitability of the business, the value of the business may decline rapidly after you die.

For some small businesses, the value may be mostly tied to the business owner and his/her relationships with the business’ clients. Should the owner die, the clients may quickly decide to find another business to buy the product or service from, which means that the business value may quickly diminish as sales and revenue dwindle. If the surviving family was counting on the value of the business to continue after the owner’s death, this may come as a rude awakening, particularly in the wake of the loss.

A buy-sell agreement may be an appropriate way to solve these problems. The buy-sell agreement is a way for you, ahead of time, to agree that the people that inherit your interest in the business will sell, and the business itself or the surviving owners will buy, your business interest in exchange for money. Such an agreement typically involves the purchase of an insurance policy, and a discussion around how to value the business (such as based on book value, or based on the sale of similar businesses in the same market). The contract in combination with the insurance policy ensures that your business interest is transferred to those that value and can utilize it, while also providing a cash benefit to your family or other beneficiaries of your estate.

Preparing for Disasters – Practical Preparedness

Disasters happen in the world, some of which may directly affect your organization.  Preparing for disasters, whether they be hurricanes, tornadoes, terrorists, hackers, power outages, fires, or earthquakes, means thinking about: (a) how your business operates today, (b) how your business would likely operate in the event of a disaster, (c) and developing some kind of testable plan for recovering from a variety of disasters that is practical but well-designed.  Preparedness is also a commitment to ongoing planning and the investment of a certain amount of resources each budget period to the process, because your plan will evolve with the extent and scope of your business as it changes over time.

In Maryland, there are not specific ethics rules that require lawyers to prepare for disasters, though common sense would tell an attorney that missing a deadline because of a disaster is still a missed deadline, and the loss or inadvertent disclosure of confidential client information is still a loss whether or not caused by a natural disaster or simple human error.   Both circumstances can lead to an ethics complaint from a disgruntled client.  For attorneys, there are a number of resources available from the ABA to help firms do a better job of preparing for a disaster.

Doctor’s offices that are joining the electronic health record system revolution because of the incentives under ARRA, also will need to have a plan for disaster recovery.  The HIPAA security regulations include standards for preparing for recovering from disasters (45 CR § 164.308(a)(7) is addressed specifically to contingency planning for covered entities and business associates).  The security regulations are cloaked in terms of “reasonableness,” which means that a covered entity’s disaster recovery planning efforts should be commensurate with the amount of data and resources it has.  So, a practice of two physicians that sees 8,000 patient visits a year is not expected to have its data available in three DR hot sites.  But, if you are a major insurance carrier, three DR hot sites might not be enough for your operation.  However, in neither case is no plan an acceptable answer.  Nor is a plan that has never been tested.

Risk Assessment

So where do you start?  The logical starting point is a risk assessment of your existing systems and infrastructure (also required of covered entities under the HIPAA security rules in section 164.308(a)(1)).  A risk assessment will guide you through gathering an inventory of your existing systems, and help to identify known and potentially unknown risks, along with the likelihood that such a risk will be realized and what you are doing now (if anything) to mitigate that risk.  The risk assessment will also help you to categorize how critical a system is to your operations, and will also identify severe risks that remain unmitigated.  This resulting list helps you to come up with a starting place for the next step: doing something about it.

The Disaster Plan

In parallel, you can also use the inventory of your existing systems and risks to develop a disaster recovery plan.  First, you now have a list of your critical systems which are your highest priority to recover in the event of a failure.  Second, you also have a list of likely risks to those systems with the likelihood based in part on your past experience with a particular disaster.  These lists help you to identify what you need to protect and what you need to protect from.  The other two questions you need to ask for each system are: (a) how much data can I stand to lose in the event of a disaster? and (b) how long can I wait to have my system restored to normal operations?

This analysis of your existing systems, risks, and business requirements will help lead the practice to a plan that includes procedures for how to function when systems are unavailable, and how to go about restoring an unavailable system within the business requirements of the practice.  Once you have your plan, and have implemented the systems or policies required by the plan, your next step is to test the plan.  Table top exercises allow you, in a conference room, to walk through the staffing, procedures, and possible issues that may arise as a result of a particular disaster scenario.  Technical testing permits your IT staff to make sure that a disaster recovery system works according to the expected technical outcomes.  Full blown testing is to actually simulate a disaster, perhaps during non-business hours, and actually run through the disaster plan’s procedures for operations and IT.

Hypothetical

As an example, suppose that you have an electronic health record system.  This is a critical system based on the risk assessment.  In the last five years, you have had a virus that partially disabled your records system causing an outage for two business days, and you have had your database crash, causing you to lose a week’s worth of data.  You have implemented two mitigations.  The first is anti-virus software that regularly updates for definitions and regularly scans the system for viruses and removes them.  The second is a backup system that makes a backup of your system’s data on a weekly basis and stores the data in a separate storage system.

Based on interviews with the practice staff and owner, the records system is used as a part of patient care.  During normal business hours, an outage of the system can result in patients being re-scheduled, and also creates double work to document kept visits on paper and again in the record system when it becomes available.  The practice has indicated that the most it can be without the system is a single business, and the most data that it can lose from this system is the most recent 4 hours of data entry (which can be reconstructed by the clinical staff that day).

You then evaluate the mitigations in place today that allow for a system recovery in the event of a likely disaster (virus or database crash based on the past experience of the practice).  The backup system today only runs once per week, which means that a crash of virus that occurred later in the week would result in more than 4 hours of lost data.  Recovery from the backup device to a new server also appears to require more than a business day, because the practice has no spare server equipment available.  So you would have to start over with the existing server (installing the operating system, database software, and then restoring the data from the backup), or purchase a new server and have it delivered to complete the restore.

The conclusion here is that while there is an existing mitigation for recovery from a likely disaster, the mitigation does not meet the business requirements of the practice.

Budget for New Sufficient Mitigations

Once you have your list of unmitigated or insufficiently mitigated risks, the next step is to look for mitigations that you could implement on your network.  A mitigation might be a disaster recovery system or service, or it might be some other service or product that can be purchased (like anti-virus software, a hardware warranty, a staff person, etc.).  At this point, the help of a technical consultant may be required if you don’t have your own IT department.  The consultant’s role here is to advise you about what you can do and what the likely costs are to purchase and implement the solution which will meet your business requirements based on your likely risks for disasters.

Once sufficient solutions have been identified, the next step is to purchase a solution and implement it.  From there, testing is key as noted above.  An untested plan is not much of a plan.

 

 

Stolen Personal Information

Hackers continue to steal data from companies the world over, with a recent victim in Sony.  In that case, Sony apparently delayed reporting the loss to the 77 million users whose data was compromised, including dates of birth and possibly credit card numbers.

In late March, Epsilon reported that hackers had stolen the names and email addresses of individuals who receive business newsletters from Epsilon’s clients, which include a number of well known companies such as Best Buy and Robert Half International.  Considering that Epsilon delivers over 40 billion emails a year for its clients, the chances have gone up of improved, targeted phishing attacks as a result of this breach, particularly for banking customers of banks that have used Epsilon for email marketing.

There should be no surprise that the regulatory penalties for data breaches continues to escalate.  Security breach notification procedures were codified into the 2009 ARRA legislation for health care providers.  ARRA Health Tech Initiatives Section 13402 of the ARRA legislation (on page 17 of the linked pdf file) puts the responsibility on a covered entity to notify its customers of a data breach where unauthorized access is gained to “unsecured” protected health information.  In laymen’s terms, “unsecured” PHI is data that is not encrypted.  So, for example, a typical relational database stores its data in physical files on a computer hard drive or array.  Some database systems encrypt these files so that you could not just open up the file in notepad and read its contents.  If a hacker were to gain physical access to the server where these files were located, he or she might not be able to read them without further access (for example, with an administrator-level username and password to directly query the database).  Notification to patients would not likely be required in this circumstance if you could show the hacker gained physical access but not database-level access.

Does your database encrypt its stored data files?  Not all database software, and not all versions of specific database software, provide for native encryption.  For example, the data files of your Microsoft Access database are not likely to be encrypted.  For performance reasons, data files for MS SQL Server databases may also not be encrypted.  But, even if your database file is encrypted, if the administrator password to the database itself is blank or easy to guess (like “admin”), you may still have trouble brewing back at the server room.

Here is a list published by HHS of data breaches reported to it under ARRA’s notification requirements.  Do you see your physician on this list?  If things continue, you may sooner rather than later!