|
|
||||||
|
09/01/2002 |
||||||
|
James B. Wieland E. Scott Johnson Appeared in RBMA Bulletin Radiology practice managers may be called upon to evaluate and negotiate technology agreements, such as software licenses. Such agreements can raise significant issues for the practice, but there is seldom room in the budget to simply turn the agreement over to legal counsel for review and analysis. This article focuses on some of the recurring issues that arise in a software license for basic medical practice systems, particularly those that include medical billing functions, and those related to the various administrative simplification standards of HIPAA. Obviously, the term of the agreement and the price for the license must be clearly stated. However, what is covered under the stated price should be considered with care. The initial fee may only cover the basic package. The range of potential "add-ons," particularly updates and enhancements that may be subsequently developed by the licensor, should be understood and negotiated. One example: Is an appropriate update automatically provided on a timely basis1 when a national HIPAA standard is modified, clarified, or updated? What, if anything, is the cost to the practice for such routine and clearly anticipated general updates? This is the same basic issue that has arisen with respect to annual software updates to conform billing software with annual updates to the Medicare RBRVS, and if the practice and its software vendor have already found a satisfactory answer there, it may only be necessary to make sure the same answer applies to HIPAA. Warranties are generally an important component of a software license. If software maintenance is covered in a separate agreement, the topic may also be covered there. HIPAA compliance is of particular importance in medical office systems; the software must be compatible with the practice's plan for its compliance with the privacy standards, such as enabling role-based access. The transaction standards will require the use of compliance data formats and content, but some medical billing software licensors will not warrant such compliance. In effect, such vendors may offer the software on a basis of "best efforts" transaction standards compliance, but refuse to accept underlying financial responsibility if the software is not. This may not be unacceptable, especially if the vendor is a known and trusted company and the practice has sufficient expertise within the practice or is willing to seek third party certification, but the practical and financial implications must be considered. The draft security standards are quite flexible in approach, but will require basic capabilities, including in most cases the ability to generate an audit trail of those who access the system.2 It is advisable to have a pre-agreed contractual mechanism for costs and timing of modifications or enhancements to the software in situations in which the cost cannot be charged to the licensor. The most reasonable dividing line between changes discussed in the previous paragraph, where a good case can be made for licensor responsibility without cost to the practice, and changes the cost of which may more logically be assumed by the practice, is probably whether the change will affect all or a broad category of users of the software and is clearly something to be anticipated on a regular basis, or whether it is a more user or local specific change. At the very least, the licensor must be obligated to make such user specific modifications, or the practice may have no alternative other than some form of work-around. A clear example would be modifications to ensure that privacy protection Lions extend to the requirements of state laws that are not preempted by the HIPAA privacy standards. At a minimum, it is useful to have an agreement as to the level of specifications to be provided by the practice, bearing in mind that the practice may simply have a generic description of a "more stringent" state privacy law, such as "no disclosure of a patient's sero-positive HIV information without separate, state mandated form of authorization." Costs, even if only on an hourly basis, for licensor programmers and other personnel, should be stated to avoid costly surprises. Border line issues must be considered with care and negotiated appropriately. For example, if the practice has any specific plans as to reliance on pre-privacy standards consents under the privacy standards transition provisions3 or anticipates special needs with respect to individual requests For special privacy protection4, those specific needs should be addressed in the context of the software license or there will be a risk of retro fixes or the need for inefficient special handling. A related issue is ownership of any custom software. Many software vendors offer some degree of specialization, at least in the medical industry, if not in a specific area such as radiology. In general, if the practice pays for a custom module, such as the state privacy module described above, should the vendor have the right to re-sell that module to other medical practices and pocket the fees? Unless the practice negotiates for that right, and includes specific language in the software development agreement providing that the practice will own the intellectual property rights embodied in the deliverables, it will not be able to prevent the developer from re-licensing the software to its other customers. In some cases, the practice may not care, so long as it has the right to use the software in its own practice. Even then, the ownership of intellectual property in custom programming developed for the practice should be considered. If full rights are acquired, it may be more expensive than if the copyright is reserved by the developer. In some instances, it may be possible to negotiate for a royalty if the developer retains the right to re-license custom developed software. To own all the intellectual property rights to custom software created by a software developer, language would typically be included in the development agreement such as: Developer acknowledges and agrees that all intellectual property rights in and to all software, documentation, graphics, text, and other materials developed in whole or in part by the Developer for Customer hereunder (the `work product'), shall be the sole and exclusive property of Customer. Developer agrees that, for copyright purposes, all work product shall be deemed works-made for-hire for Customer. In the event that any copyrightable work product created by Developer hereunder shall be determined not to be a work-made for-hire for Customer, Developer hereby assigns to Customer, all the Developers right ,title and interest in and to said work product or applicable portions thereof, gender copyright and otherwise. This general statement of ownership will be more limited when the Developer modifies its pre-existing software in combination with custom programming, in which case generally it would retain ownership of its underlying software, and would provide adaptations of such pre-existing software to the practice under license.5 A clear HIPAA issue is whether the licensor will be a "business associate" under the HIPAA privacy standards. Generally speaking, the position of the regulators seems to be that a business associate agreement will be required if the agreement contemplates that the licensor has any means of access to a server that contains protected health information, even if that access is only incidental to maintenance or correction of problems. A related issue is the right of a business associate under the privacy standards to permit access to practice's protected health information to third parties with which it contracts. The key is the wording of the agreement with the business associate, in this case, the software license. The privacy standards permit, but do not require, that the business associate be permitted to use and disclose the protected health information to which it has access, among other things, for "the proper management and administration" of the business associate, if the business associate obtains "reasonable assurance" that the third party will safeguard the protected health information.6 Language in the software license such as, "Notwithstanding anything to the contrary in this agreement, (Licensor) will not disclose information that is protected health information under (the HIPAA privacy standards) to any third party, i. e., to any other legal entity or to any individual that is not an employee or full time member of (Licensors workforce) who under a specific, written confidentiality agreement with (Licensor with respect to such protected health information without the specific, advance written consent of Licensee" will provide the radiology practice with an opportunity to ensure that any third party disclosures are reasonable. Something of a "stealth" issue can arise in software licenses, especially those on an ASP model involving the storage of the practices, information on the licensor's server. If the licensor has the right to access, de-identify, and aggregate the practice's data with similar data from other licensor's, the licensor can assemble a database that may have commercial value. Most radiology practices would want some financial recognition of the practice's contribution to that value, as well as a strong undertaking by the licensor to comply with the standards for de-identification specified in the privacy standards. In addition, the practice may wish to control or prohibit commercialization of de-identified aggregated data, utilizing a provision such as: "Licensor acknowledges that certain data and materials will come into its possession or knowledge in connection with this Agreement, all of which is confidential or proprietary information of Customer including, without limitation, all information concerning or relating to patients and business records) ("Customer Data'). All Customer Data shall remain the sole property of the Customer, and shall be held in confidence by Licensor in accordance with the (confidentiality J provisions of t his Agreement. Licensor agrees to use the Customer Data only in connection with its performance under this Agreement and to release it only to those employees of Licensor requiring access thereto for such performance (each of whom shall have signed confidentiality agreements with Licensor regarding confidential information of Customer and its patients) or as may otherwise be required by law, in which case Licensor shall provide written notification to Customer of such impending disclosure. Developer shall not, without Customers prior written consent, copy, distribute, prepare derivative works, databases, or other data compilations, commercialize, or otherwise make any icse of the Customer Data, in whole or in part, except as may be necessary to perform services for Customer hereunder. Finally, most software licenses contain a choice of law clause which will usually state something like "This agreement will be interpreted according to the laws of the state of ____ , without reference to its choice of law doctrines." If both the practice and the licensor are in the same state, the appropriate choice of law is generally that state. However, in some cases, such as a licensor with a multi-state presence, state law other than the law of the state in which the radiology practice operates may be proposed. In the context of a software license, choice of a "foreign" state may have significant legal consequences. Some states have enacted legislation in recent years specifically directed to "computer information transactions," such as software development and software license agreements. The Uniform Computer Information Transactions Act (UCITA) has been enacted, in slightly different versions, in some states. These laws provide default terms, "gap fillers," and rules of construction that can affect warranties and other rights and obligations of software licensees. While contract terms govern, in some instances, the manner in which a particular provision in a soft ware development or license agreement is construed could vary depending on which state's laws apply.
Footnotes 1Timely in this context means not only installed, but tested and de-bugged in advance of the date upon which compliance is required by the practice. 2The provision regarding audit trails is proposed to be included in the regulations at 42 C.FR § 142.308(a), providing "Administrative procedures to guard data integrity, confidentiality and availability. . .These procedures include the following requirements... (6) Internal audit (in-house review of the records of system activity (such as logins, file accesses, and security incidents) maintained by an organization)." 3In general, protected health information obtained prior to the effective date of the privacy standards can continue to be utilized under prior, state law consents, but such uses are still subject to HIPAA privacy standards requirements. Particularly if a practice is changing software vendors, compatibility between systems for pre- and post- privacy standards compliance date protected health information is important. 4The privacy standards expressly permit an individual to request special handling of the individual's protected health information. While a covered entity is not required to grant the request, because of the administrative burdens of special handling in the environ ment of the HIPAA privacy standards, refusal may be difficult in some situations, e.g., an elderly patient wants statements sent to the office of a family member to protect a frail spouse from the stress of knowing of a serious medical condition. Radiology practice managers must ensure that billing software can comply with such requests in an efficient manner. 5This and other suggestions as to possible contractual wording are provided as illustrations only and not as legal advice. 645 CFR § 164.504 (e)(4)(A). |
||||||
|
Ober, Kaler, Grimes & Shriver Maryland
Washington, D.C. Virginia |
||||||
