The Digital Office
As with greatness, some medical practices are born to use HIT, others learn how to use HIT, and still others have HIT thrust upon them. The prevalence of HIT goes beyond the EHR and can touch every aspect of the practice. Such prevalence impacts different groups in different ways, so careful scrutiny must be paid to the vendor contract in order to protect against potential disaster.
The following topics are recurrent hot-button issues that crop up repeatedly. Spotting these issues and measuring their impact on the practice is critical in developing an optimal HIT vendor relationship. The following is designed to raise awareness of potential pitfalls in a HIT vendor contract, but should not be construed as legal advice.
Service Level Terms. Does the contract require the vendor to maintain certain objective levels of service? For example,
- Does the contract spell out the ways that the vendor will minimize service outages?
- Does it require the provider to respond to problems within a certain time?
- Does it state when and how customer service is available?
If not, the group needs to address these matters within the contract to its satisfaction because when a medical group effectively outsources one of its functions via the use of technology, an outage or extended service problem can be hugely expensive.
Data. It goes without saying that most HIT programs generate or store data in one form or another. But,
- Does your contract state who owns the data during and after the term — and, more importantly,
- Does address these issues to your satisfaction?
Another sticky wicket in data management is whether the data is exportable in a usable format so that the group can transition to another provider, if necessary. The group has to maintain flexibility in this regard and doing so requires an understanding of where the practice is going from a business standpoint, how the technology affects that plan and how to structure the vendor contract to support that plan.
Security. Even assuming business associate agreements where one size fits all — which they are not — what if the vendor says it is not a business associate?
The HIPAA rules define ‘‘business associate’’ generally to mean a person who performs functions or activities on behalf of, or certain services for, a covered entity that involve the use or disclosure of protected health information.
- Section 13408 of the HITECH Act states that an organization providing data transmission of protected health information to a covered entity (or its business associate) and requiring access on a routine basis to such protected health information is a business associate for purposes of the Act and the HIPAA Privacy and Security Rules.
- On the other hand, the Department of Health and Human Services has explained that entities that are mere conduits for the transport of protected health information, but do not access the information other than on a random or infrequent basis, are not business associates.
While there are certainly clear-cut examples along the business associate-conduit spectrum, what constitutes “access” and “routine” often blend into shades of gray. Transactions in these gray areas can leave the unwitting practice group unprotected, if it simply signs the standard service contract. The practice should pay close attention to whether the contract creates a business associate or conduit relationship; whether the security obligations imposed on the vendor are sufficient; and whether the contract provides internal protections, such as indemnity clauses or bonding/insurance requirements
Insurance. Insurance is but one spoke shooting off the hub of the digital office, but it is an important one. Do not assume that the insurance covering the server automatically protects content residing on the server. Stored data receives interesting treatment under certain types of insurance and the group must ensure that its data is covered.
Cooperation in Transition. No one likes to think about the end of a relationship when it is just beginning, but like in any prudent business undertaking, the HIT contract has to provide an exit strategy that is clear and fair. The group should bargain hard for an affirmative obligation on the part of the provider to act in good faith to ensure an orderly transition to a new provider.
Legal Liability. I was surprised recently in reviewing a contract as counsel in a litigation matter that not only did the contract not have an indemnity provision, it also lacked any clear statement of ultimate responsibility for creation and use of the data.
Many HIT ventures are a collaborative effort with each side bringing something to the mix resulting hybrid product for use in the practice. With so much scrutiny at the federal and state levels on medical data, and penalties ranging from fines to license revocation to Medicare exclusion, it is imperative that the HIT vendor contract spell out who is ultimately responsible for use of the data and to protect one party from liability generated by the conduct of the other party.
No one wants to find out the answers to these questions when it is too late — the system crashes, the contract expires, the US Attorney calls. The importance of the HIT vendor contract to the group’s practice requires careful attention to detail to make sure the essential elements of the contract track the same course as practice’s business plan.