ELECTRONIC MEDICAL RECORDS: A PRIMER FOR ESRD FACILITIES MAY 2009

Transcription

1 MAY 2009 ELECTRONIC MEDICAL RECORDS: A PRIMER FOR ESRD FACILITIES Andrés J. Gallegos, Esq. Robbins, Salomon and Patt, Ltd. 25 E. Washington, Suite 1000 Chicago, Illinois Tel: (312) Fax: (312) agallegos@rsplaw.com

2 INTRODUCTION T he benefits of electronic medical records (EMR) technology adoption and implementation are significant and clear. Foremost, EMR implementation has been demonstrated to dramatically improve survival in patients with chronic diseases. As EMR provide clinicians with electronic access to real-time patient information, medication errors can be reduced and unnecessary tests can be eliminated, which can dramatically improve patient care. Adoption of EMR can also improve process efficiencies, improve communication between members of the interdisciplinary team, and between the dialysis facility and kidney transplant centers, can facilitate regulatory compliance, and enhance revenue. Nevertheless, adoption and implementation of EMR within the ESRD community has been slow given the significant financial and time investment required. However, with the passage of the American Recovery and Reinvestment Act of 2009, which contains $17.2 billion in incentives through Medicare and Medicaid for the meaningful use by healthcare providers of certified EMR technology, dialysis facilities are looking to adopt EMR. A dialysis facility committed to making an investment in EMR technology will most likely license one of the many commercial off-the-shelf EMR software products, and have portions of the software customized, or have specific add-on applications developed, to meet its unique requirements. Quite frequently, given the significant financial investment involved, hospitals or other third parties (such as software developers or pharmaceutical companies) may offer to donate the software to a dialysis facility, or may seek the practice s collaboration to test and evaluate new software or to develop proprietary software in exchange for a reduced license for the software. Can a dialysis facility afford to look a gift horse in the mouth? It better. There are a number of legal and tax issues implicated when a hospital or any other third party looks to donate EMR software to a dialysis facility. This guide overviews for dialysis facilities and their practice management companies, the key legal issues to contemplate when considering to accept a donation of EMR software mainly the federal Anti-kickback Statute and federal physician self-referral law and provides an overview of the various TABLE OF CONTENTS EMR Software Donation: AKS & Stark Donation Requirements, Pg. 2 Beta Test Site License, Pg. 3 Understanding the License Agreement, Pg. 4 Developing EMR Software or Applications, Pg. 8 About the Author, Pg. 13 About Robbins, Salomon and Patt, Ltd., Pg Robbins, Salomon and Patt, Ltd. 2

3 business and legal issues that must be addressed when negotiating to license or develop EMR software or a software application. EMR SOFTWARE DONATION: ANTI- KICKBACK STATUTE (AKS) SAFE HARBOR & STARK LAW EXCEPTION The AKS safe harbors describe specific business practices and transactions that will not be treated as violations of the AKS. In the absence of full compliance, a facts and circumstances test can be used to gauge the risk of being deemed in violation of the AKS. Unlike the AKS, if the Stark prohibition applies, an exception must be found to allow the arrangement. The AKS EMR safe harbor and Stark EMR exception significantly parallel each other, except as otherwise indicated below. PROTECTED TECHNOLOGY. Only software and information technology necessary and used predominately for EMR, such as creating, maintaining receiving and sending EMR are protected. The software must contain electronic prescribing capability, either through an electronic prescribing component or the ability to interface with your existing electronic prescribing system. Such systems must meet the applicable e-prescribing standards under Medicare Part D at the time the items and services are provided. The software must also be interoperable (i.e., able to communicate and exchange data accurately, effectively, securely, and consistently with different information technology systems, software applications, and networks, in various settings). Software for non-emr purposes, such as billing and scheduling, are permitted, as long as they do not predominate. Tax Issues Donation of EMR software and services has potential federal tax implications to both the donor, if it is a tax exempt entity, and the recipient, as the value of the donated items and services may be considered income. Training, maintenance, and help-desk services also are permitted, but not direct staffing. Hardware is excluded. PROTECTED DONOR & RECIPIENT. A protected donor under the AKS safe harbor is an individual or entity that provides services covered by a federal health care program and submits claims or requests for payment either directly or through reassignment to a federal health care program. That definition encompasses hospitals, facilities, physicians, nursing and other facilities, pharmacies, laboratories, oncology centers, dialysis facilities, a broad array of health plans, and others. Protected donors under the AKS safe harbor do not include pharmaceutical, device, durable, medical equipment or other healthcare manufacturers, or vendors that indirectly furnish items and services used in the care of patients. Donors permitted under the Stark exception are any entities that furnish designated health services to physicians. A protected recipient under the AKS safe harbor is an individual or entity engaged in the delivery of healthcare. That includes physicians, group practices, physician assistants, nurse practitioners, nurses, therapists, audiologists and pharmacists; dialysis, nursing and other facilities, federally qualified health centers, and community health centers, laboratories and other suppliers and pharmacies. Recipients permitted under the Stark exception are physicians Robbins, Salomon and Patt, Ltd. 3

4 CRITERIA FOR SELECTING RECIPIENTS. Any method of selection, except donors may not take into account directly or indirectly, the volume or value of the recipient s referrals or other business generated between the parties. Examples of Recipient Eligibility Criteria Total number of prescriptions written Size of medical practice (e.g. total patients, total patient encounters, or total relative value units) Total number of hours practicing medicine Whether the physician is a member of donor s medical staff, if the donor has a formal medical staff The level of uncompensated care provided DONOR S PROHIBITIONS. Must not donate EMR software if the recipient possess or has obtained items or services equivalent to those provided by the donor. The donor may not take any action to limit or restrict your use, compatibility or interoperability of the EMR software with other electronic prescribing or electronic health record systems or your ability to use the items or services for any patient without regard to payor status. The donor may not shift costs of the items or services to any federal health care program. The donor cannot pay more than 85% of the costs for the items and services. RECIPIENT PROHIBITIONS. Neither the recipient nor their practices may make the receipt of items or services or the amount or nature of the items or services a condition of doing business with the donor. WRITTEN AGREEMENT. Prior to receiving the software, the arrangement must be set forth in a signed written agreement that specifies the items and services being provided, the donor s costs of the items of services, the amount of your contribution, and it must cover all of the items and services to be provided by the donor. REQUIRED COPAYMENTS. Before the receipt of the items and services, you must pay 15% of the donor s costs for the items and services and the donor may not finance your payment. This is an absolute financial requirement. The value of in-kind services provided by you will not be counted towards the 15% contribution requirement. BETA TEST SITE LICENSING B eta testing is third phase of a software s release life cycle, where the software is tested immediately prior to its commercial release. Dialysis facilities may be willing to serve as a beta test site for the development of EMR software as a means to defray the cost of the software. As a beta test site, you will be required to implement the software and provide the software s developer with reasonable feedback regarding the software s functionability and usability by testing, evaluating, providing audits, and identifying any and all observed errors, 2009 Robbins, Salomon and Patt, Ltd. 3

5 bugs, malfunctions and desired additional features in the operation of the software. This can be a time consuming endeavor and requires that you work hand-in-hand with the developer or the developer's team. Although you are contributing to the program's development through your evaluation and testing of the software, you typically are not granted any ownership rights to the software itself. Your willingness to serve as a beta test site must be subject to a beta test site license agreement that specifies, among other things, your obligations with respect to the testing of the software, the limits of your use of the beta software, the length of your testing and evaluating obligations, confidentiality provisions (protecting the developer s trade secrets) and your subsequent rights to the commercial version of the software, its upgrades, enhancements and future versions of the software, once released. In addition, the beta test site license agreement will contain most of the same provisions of the software s license agreement (see below). If you are willing to serve as a beta test site for future upgrades, enhancements or future releases of the EMR software it should be included in the beta test site license agreement. UNDERSTANDING THE LICENSE AGREEMENT A s technology licensing is significantly dissimilar to the types of contracts physicians typically negotiate, understanding the various business and legal issues that should be addressed when negotiating an EMR license is a vital first step to ensuring a facility is able to satisfy its business requirements and maximize a return of its significant investment. EMR software is "licensed" as opposed to "purchased." Except in some instances where the software or an application is specifically developed for a facility, the facility does not become the "owner" of the EMR software. Rather, through a license agreement, the facility is granted the right to use the software, subject to certain restrictions, conditions and parameters set forth in the license agreement, and in consideration of the license fees paid. Upon termination of the license agreement, the facility's use of the software must discontinue and the software must be destroyed or returned to its developer (i.e., its licensor). As the licensing of EMR software is a significant financial investment, the terms of the license agreement should be negotiated, although some, if not most, licensors will balk at negotiating their standard form of license agreement. Software Release Life Cycle Pre-Alpha (Initial Development) Alpha (Internal Test) Beta (Public Test) Release Candidate General Availability 2009 Robbins, Salomon and Patt, Ltd. 4

6 Key Components of a License Agreement What Happens to Your License in Bankruptcy? The Bankruptcy Code, Section 365(n), provides you with protections from being stripped of your rights to continue to use the licensed intellectual property if the licensor is in bankruptcy. If the licensor in bankruptcy or the trustee rejects the license (which they may do) you can elect to retain your rights to the licensed intellectual property, including the right to enforce an exclusivity provision and your rights under a source code escrow agreement or any other agreement supplementary to the license. In return, you must continue to pay any required royalties. LICENSE SCOPE. The scope of the license identifies what the license specifically covers, where it can be used, who and how many users can use it. You should attempt to negotiate these provisions as broadly as possible. A facility will likely receive "nonexclusive" as opposed to "exclusive" rights to utilize the software. Exclusive rights grant a facility, alone, the right to utilize the software in a specified field of use, which can be defined broadly (e.g., "for use in any and all healthcare facilities and medical practices") or narrowly (e.g., "for use limited to the chronic dialysis facility identified in this license agreement"). The grant of exclusive rights will preclude the software developer and its resellers from licensing the software to any person or entity within the defined field of use in which the exclusive rights were granted. If the facility assisted in developing a portion of the software or has paid to customize the software or a software application, exclusive rights may be an important issue, at least to that portion of the software the facility helped develop or paid to have customized. A grant of nonexclusive rights means the licensor may license the software to other persons or entities, without restriction. The license may be machine-specific, that is, the software is installed only on specifically designated computers; sitespecific, meaning the software is installed on any number of computers at a certain facility location; enterprise-wide, that is, installed on any number of computers at any site owned or operated by the facility or its affiliates; or based on some other criteria, such as being tied to a number of concurrent users. You will need the ability to assign the software to your successors, affiliates and assigns merely by providing notice to the licensor. If you serve as a management company to other chronic or acute dialysis facilities or units, or if you re planning to open additional facilities or units, you may require the right to sublicense the software to them if they do not license the software directly themselves Robbins, Salomon and Patt, Ltd. 5

7 LICENSE FEES, TERM & TERMINATION. The license fee can be a global fixed price or variable depending upon the number of users, records created, etc. While the licensor will desire to have the license fee paid up front, you should try to negotiate installment payments tied to installation and implementation progress or milestones. Also, what the fee covers should be clearly defined. The license fee is generally the consideration for the current version of the software's installation, initial training, the right to use the software during the license term, and to receive the warranty benefits. Support and maintenance beyond the warranty period is typically not included in the license fee. Future releases, enhancements or upgrades of the EMR software are typically subject to a separate license agreement and license fee. However, you should attempt to negotiate the license fee to include future releases and upgrades, particularly those released within 12 months from the date of its initial license. Sublicensing If you will sublicense the EMR software to your managed practices, you will have to enter into separate license agreements with those practices, and pass along the warranties and remedies you received from the software s developer. The license can be irrevocable or revocable during the license term. If irrevocable, typically, neither party may terminate the license agreement before its natural expiration, unless the other party breaches a material license term. However, a facility should have the right, at any time during the license term, for any or no reason, to terminate the license agreement upon notice to the licensor. The licensor should only be able to terminate the license agreement upon the facility's breach of, ideally, narrowly and clearly defined triggering events, and then only after written notice to the facility of the alleged breach and the facility's failure to timely cure the breach within a reasonable period of time. As important as trying to negotiate the narrowing of the licensor's right to unilaterally terminate the license agreement, a facility should also focus its negotiations on what happens upon termination. A facility should be able to continue using the software for some reasonable period of time until a substitute EMR software can be licensed and implemented. The duration of a facility's right to use the EMR software is defined by the license term. The license term can be perpetual or for a fixed length of time. While the right to use the software may be perpetual, it doesn't necessarily follow that the support or maintenance will be also. Moreover, if the license is perpetual, it doesn't mean that the facility must use the software in perpetuity, only that it may. INSTALLATION, TRAINING, SUPPORT & MAINTENANCE. Software installation, user training, technical support and software maintenance services need to be set out either as part of the license agreement or a separate agreement, and should detail the scope of those services. If they will be provided for fees in addition to the license fee, which is typical, particularly for technical support and software maintenance services beyond the software's 2009 Robbins, Salomon and Patt, Ltd. 6

8 warranty period, the fees, or at the very least the formula by which to calculate the fees, need to be specified. Sunset Provisions Sunset provisions are often included by licensors, which allow them to provide support only for the latest software version, discontinuing support for older versions. Resist, if possible, such provisions unless the latest software versions are provided to you at no additional cost. EMR software installation and implementation can be a lengthy process, spanning over four to six months and beyond, depending upon the software, number of users, number of existing records to be converted, training requirements, etc. User training should be provided on the facility's site if at all possible. Training may be provided by the licensor to all of a facility's employees or to a key few who then will act as trainers to the remaining employees. Technical support services will be of critical importance, particularly as a facility begins implementing the EMR software. Support services usually require the licensor to make available its technical experts via telephone, on-site or remotely, either 24/7 or during normal business hours. Initial software maintenance services, to correct bugs and other problems, should fall under the warranty terms, and only after the warranty expires should a facility be required to pay a separate maintenance fee. Responsiveness is also an important issue to address as it relates to technical support and software maintenance services. Minor software issues should be corrected within five to seven days. Critical software issues must be addressed immediately, within minutes or hours. If complete fixes cannot be made within the required timeframes, workarounds should be provided. Be aware that using someone other than the licensor or its designated maintenance provider to correct a problem will most likely negate the software's warranty. WARRANTIES & REMEDIES. The warranty provisions should define the licensor s obligations to you if the software does not perform as represented, as documented or upon a failure of the software or any of its applications. If so, it is imperative that all of the representations and performance specifications be in writing, clearly defined, and incorporated into the license agreement. Licensor s typically strive to limit the scope and duration of the warranties, and disclaim responsibility as much as possible, at times offering the software as is. While the licensor will argue its warranty provisions are standard, you should try to broaden them as much as possible, even if you have to pay more for expanded warranties. Warranties should also extend to any upgrades, enhancements or modifications to the software. The greatest risk and legal exposure to a facility utilizing EMR may arise from a defect in the EMR software that causes or contributes to patient injury or fatality. Licensors should be 2009 Robbins, Salomon and Patt, Ltd. 7

9 required to obtain and maintain, for the duration of the license term, sufficient liability insurance, and be required, ideally, to name the licensee as an additional insured. Another significant risk may arise from a claim by a third party that the licensed EMR software infringes upon their intellectual property trademarks, copyrights, trade secrets or patents. Ideally, a facility can negotiate for the licensor to defend, indemnify and hold it harmless from infringement claims. If not, the licensor should be required to obtain the right for the facility to continue using that portion of the software that is infringed, or to modify that portion so as to make it non-infringing. In addition to indemnification, other possible remedies may include having rights to access or have an information technology consultant access on your behalf the software s source code to correct that which the licensor is unable to, the right to receive a partial refund, the right to terminate the agreement and to claim damages if the licensor is unable to support the software as required. SOURCE CODE. Access to the software s source code (i.e., the code written in human-readable programming language) is critical to you if the licensor is unable or unwilling to correct a problem with the software, or deliver future modifications or upgrades. Without source code access, if the licensor goes out of business, ceases to support the software or fails to cure a material breach of its duties under the license agreement, then your operations could be compromised. While the licensor will be unwilling to provide you with unfettered access to the source code, access can be provided through an escrow arrangement where a third party maintains possession of a copy of the source code for your beneficial interest. A source code escrow agreement will be required, which clearly defines events triggering your or your information technology consultant s access to the source code. DEVELOPING EMR SOFTWARE OR APPLICATIONS M ost commercial off-the-shelf EMR software products 1 will require some degree of customization in order to meet your clinical and operational needs. If, however, you find that you have greater needs than what customized existing EMR software products can offer, you may decide to engage the services of a software developer to develop proprietary EMR software, or you may be offered, or seek to assist, a hospital or other third party in co-developing proprietary EMR software. Software development is a very long, timeconsuming and collaborative process, whether you are undergoing the development by yourself or you are collaborating with a codeveloper. To satisfy, in part, your AKS and Stark Law requirements, to protect your significant financial and time investment, and to delineate your rights and obligations vis-àvis your co-developer and the software developer, you will need to negotiate a software development agreement. Key Components of a Development Agreement DEVELOPMENT OF SOFTWARE OR APPLICATIONS. Whether it is for the development of a customized application of existing software, or the wholesale development of a new software 1 For a price comparison matrix of various off-the-shelf EMR vendors, visit prices/ 2009 Robbins, Salomon and Patt, Ltd. 8

10 product, the development provisions need to define the scope, specifications and requirements for the EMR software or the application, and define the hardware and platform requirements needed to optimally run the software or application. One or more statements of work are developed that sets forth the software's or application s specifications, development sequence, timing and development milestones. Unless you have some software development expertise, your role will be to define what you want the software or application to do and look like. The software developer will then define the technical requirements needed to make the software or application do what, and look like, you envisioned. CONTRIBUTIONS, PROPRIETARY RIGHTS & OWNERSHIP. The contributions, proprietary rights and ownership provisions should clearly delineate what each party s monetary, technical and intellectual property contributions will be. It is somewhat akin to a prenuptial agreement, in so far as each party to the development agreement identifies what is theirs coming into the relationship (i.e., defined trademarks, trade secrets, algorithms, business methods, copyrights, patents, etc.) what will remain theirs upon the conclusion of the development agreement, and what will be jointly owned. With respect to what is yours going into the relationship, you are not losing ownership of that intellectual property, you are licensing granting rights to use -- that intellectual property to the other party or parties to the development agreement for the defined limited purposes of developing the software or application. Likewise, the co-developer or software developer will retain ownership of its contributed intellectual property, and will license it to you for the limited purpose of your use in the development and eventual use of the software or application. What is jointly developed should be jointly owned, unless you engage the software developer s services as an independent contractor and not as a co-developer. If you have a co-developer, obviously, the strength of your claim of ownership to, and therefore, the degree of your ownership of, Indemnity Requirements the newly developed intellectual property is As each party to a dependent upon the degree of development agreement your contributions. If you will be contributing various forms of contribute more than your codeveloper (e.g., more money, intellectual property, it is human capital or intellectual property), then, arguably, vital for a facility to be your percentage of ownership indemnified by its codeveloper from potential intellectual property should in that newly developed infringement claims by be greater than your codeveloper s. third parties arising from the co-developer s contributions. If, however, you have no co-developer, in order to defeat a ownership claim by a software developer who is an independent contractor and not your employee, the law requires there be an express writing between the parties specifying that the work is specially ordered or commissioned and considered work made for hire under the 1976 Copyright Act, as amended. Absent a writing addressing ownership, your independent contractor software developer will have a legitimate claim of co-ownership. If your software developer is your employee, no separate writing is required as the work made for hire doctrine is deemed to apply Robbins, Salomon and Patt, Ltd. 9

11 DELIVERY, REVIEW, ACCEPTANCE & REJECTION. The delivery, review, acceptance and rejection provisions of the development agreement specify when delivery of certain portions of the software or application must be tendered for your review, acceptance or rejection, and what "delivery" constitutes. Delivery should not be deemed to occur until what is tendered to you substantially meets the specifications for the delivery. The scope of your review is to determine if the deliverable conforms to its specifications. The review provisions will specify the amount of deliverable and the methods or process by which to accept or reject it. If you reject the deliverable, you will be required to specify the reasons for your rejection, which should then trigger a process by which the reasons for your rejection are fixed and returned to you for additional review and acceptance or rejection, until it is finally accepted. The software developer will only be able to correct those errors that can be replicated. The software developer's ability to correct errors in the rejected deliverable should be limited in number of attempts. If it is unable to correct errors after two or three times, you should have the right to suspend or terminate the development agreement without further obligation to the software developer. If after your acceptance of any specific deliverable you want additional changes or modifications to that deliverable, it will likely result in a "change order," which would require an additional amount to be paid to the developer. Change orders will likely affect the budget and the agreed-upon timetable may need to be adjusted to account for the additional work requested. It is typical to have the option to suspend or terminate the Work Made For Hire The general rule is that the person who creates a work is the author of that work, with one exception the Copyright Act defines a category of works called works made for hire. If a work is made for hire, the employer, and not the employee, is considered the author. development agreement, without further obligation to the software developer, if the software developer, for reasons other than force majeure, is unable to deliver what is required pursuant to a predefined time table. You, however, cannot be the reason for the software developer s delay in performance. SOURCE CODE ESCROW. Just as discussed above with respect to software license agreement, upon your acceptance of any software or application deliverable, the software developer should be required to deposit a fully commented and documented copy of the source code for the deliverable into escrow with a third-party source code escrow agent, subject to a source code escrow agreement. Upon the final completion of the software or application, as a condition of your final payment, the software developer should be required to deposit a complete copy of the software s or application s source code into escrow. The escrow account can be accessed by you upon certain triggering events defined in the development or source code escrow agreement. If the software or application is developed as "work made for hire," the source code for that portion of the software or application that is not the software developer s contribution should be given to you, and only the source code for the software developer s contribution should be escrowed. If the software developer corrects any defects in, or provides any revision to, the software or application, the software developer should be required to simultaneously furnish the escrow agent with a corrected or revised copy of the source code for the software or application Robbins, Salomon and Patt, Ltd. 10

12 Progress Review Meetings It is also important that the development agreement also address and schedule progress review meetings between you and the software developer. Progress review meetings are intended to assess progress of the development, and to determine what variances there are, if any, to the proposed development schedule and budget. The source code escrow agreement will typically require the escrow agent to confirm and provide you notice of all source code deposits. LICENSE OF SOFTWARE. The development agreement should also contain terms and conditions for the licensing of the software or application to each of the parties subject to the development agreement. The license provisions should contain those provisions as discussed above in UNDERSTANDING THE LICENSE AGREEMENT. DERIVATIVE WORK. For copyright purposes, derivative work means a new work based upon an original work to which enough original creative work has been added so that the new work represents an original work of authorship. As between you, your codeveloper or software developer, who will have the right to develop derivative work of the EMR software or application? Undoubtedly, the fruits of your efforts (and investment) will yield a highly marketable product that will have great appeal in the ESRD market. Tweaking the product may result in a viable product with application to other providers of chronic conditions or physician practices in general. It is common for the software developer to request a first option to develop derivative work for you. Which, if granted, means that before you would be able to engage another party to create the derivative work, the software developer will have an opportunity to submit to you, for your acceptance or rejection, a proposal for the development of the derivative work. MAINTENANCE AND SUPPORT. Follow-on maintenance and support will be critical whether the software is developed for commercial release or for your internal purposes only. The development agreement should include provisions that address the software developer s obligation to provide continuing maintenance and support to you and other end users Robbins, Salomon and Patt, Ltd. 11

13 MARKETING. What rights, obligations or restrictions will you or your co-developer or software developer have to commercialize and market the software or application? Will each party have equal rights to the general market? Will the market be divided into defined fields of use between the parties? If marketing rights are intended, financial contributions to the marketing efforts need to be settled, along with the defining and dividing of royalties, and other operational issues. The marketing provisions need to address all of that. If it is intended to develop a commercially marketable product, the development fee may be structured as part time & materials and royalties from subsequent commercial licensing. CONCLUSION T he benefits of EMR adoption and implementation are clear. Although global adoption has not yet taken place within the ESRD community -- mainly attributed to the significant financial and time investment required with the great emphasis being placed upon EMR adoption and implementation by the Obama Administration, it will occur. EMR licensing and transition to an EMR system is a complex process. In addition to the issues discussed above, dialysis facilities must ensure their EMR comply with the Security Standards of the Healthcare Information Portability & Accountability Act of 1996 (HIPAA), and the privacy and security requirements of the Health Information Technology for Economic and Clinical Health Act of 2009 (HITECH Act). The proposed privacy and security rules for the HITECH Act are just now being released. Dialysis facilities and their management companies must protect their EMR investment. It all begins with understanding the parameters relating to EMR donation, the evaluation, licensing and development process, and it continues with seeking professional advice and analysis of the legal issues and tax issues associated with receiving a donation, licensing or developing EMR software or software applications, and implementing the technology. DISCLAIMER Consultation with legal and tax advisors is advisable before entering into legal relationships or transactions which implicate federal and state healthcare laws. Accordingly, this guide is not intended as legal or tax advice for a particular transaction, nor is this article a substitute for consultation with professional advisors on the matters discussed herein Robbins, Salomon and Patt, Ltd. 12

14 ABOUT THE AUTHOR A ndrés J. Gallegos, Esq., is a corporate and corporate healthcare partner at Robbins, Salomon and Patt, Ltd. Mr. Gallegos serves as corporate counsel and advisor to a number of corporations and healthcare providers and provider groups throughout the United States. Mr. Gallegos regularly counsels dialysis facilities and their medical management companies on formation, shareholders and governance issues, medical director and allied health professional employment matters, contacting issues with third party payors and other parties, information technology and intellectual property issues, joint ventures and market expansion; and compliance issues under the Stark Law, Anti-kickback Statute, HIPAA, and state licensing statutes. Mr. Gallegos is a frequent lecturer on healthcare law issues before local and national trade organizations, and has authored articles specific to the ESRD community, which have been featured in Renal Business Today, a national practice management journal. Mr. Gallegos can be reached at (312) , or at agallegos@rsplaw.com. ABOUT ROBBINS, SALOMON AND PATT, LTD. (RSP) HEALTHCARE LAW PRACTICE O ur talented healthcare transactional attorneys and litigators assist healthcare professionals navigate through and succeed in the increasingly regulatory and ever-changing healthcare environment. Our attorneys have great breadth and depth of experience protecting, and providing innovative, yet practical solutions to issues facing health care professionals. Our healthcare clients include physicians and physician groups, dentists and dental groups, practice management companies, independent physician associations, independent dialysis facilities, ambulatory surgery treatment centers, diagnostic imaging centers, durable medical equipment companies, urgent care centers, home health agencies and other professional healthcare providers and suppliers. Our healthcare attorneys serve as the functional equivalent of "in-house counsel" to a great number of our corporate healthcare clients. RSP represents healthcare professionals in a broad array of business and regulatory matters, litigation and in administrative hearings. We have significant experience in advising clients in all aspects of their professional evolution and operations, including: practice formation, recruitment and employment issues, equipment and real estate leasing and acquisitions, daily operations and practice management issues, joint ventures, licensing and disciplinary issues, malpractice defense, managed care issues, billing, Medicare and Medicaid reimbursement issues, sales, mergers and acquisitions; market expansion, antitrust matters, and state and federal regulatory compliance issues, including Stark Law, Anti-kickback Statute and HIPAA Robbins, Salomon and Patt, Ltd. 13

15 For more information about our healthcare law practice, please contact any one of the following: Andrés J. Gallegos (312) Dr. Michael J. Hriljac (Of Counsel) (312) Michael D. Schlesinger (312) Tracy E. Stevenson (Litigator) (312) Alan J. Wolf (312) Robbins, Salomon and Patt, Ltd. 25 E. Washington, Suite 1000 Chicago, Illinois Tel: (312) ; Fax: (312) Chestnut Ave., Suite 101 Glenview, Illinois Tel: (847) ; Fax: (847) Robbins, Salomon and Patt, Ltd. 14