Understanding and negotiating software contracts is an often-overlooked part of the EHR implementation process. Yet knowing the terms and conditions for data, service, support, upgrades and backups is essential. Chad Eckes and Edgar Staren from the Cancer Treatment Centers of America provide an overview of key terms and considerations in a (2009) HealthCare IT News article available here.
In particular, the terms and their definitions are important to understanding the uses and safeguards of the EHR system. For instance, the fee structure can vary widely across different vendors–and different implementations with the same vendors. If you anticipate a slowing-down of business during implementation, making sure the fee schedule matches your expected income is an important consideration.
Who owns which data in an EHR is also important. Do you own your patient data? How about backups? Who can access that data? And can you access and manipulate the source code of your EHR, or is that protected and owned by the software company? The authors call this “escrow of source code,” and it’s a truly vital component of any software contract.
But by and large, the biggest financial cost to implementers of EHRs is training, support and service. A good EHR contract includes defined roles, responsibilities, timelines and metrics for understanding progress. Regular meetings should be specified, and a way to reschedule them if needed. If a consultant leaves before the end of the service period, the contract should specify transition protocols and who will support those costs.
These tips and tricks can help you to avoid some of the pitfalls, and understand some of the protections and benefits in EHR contracts.
- Your contract should fit your needs, and negotiating to ensure that is critical.
- The contract exists to protect both parties, and needs to be specific enough to do that.
- If implementation will reduce your income, be sure to account for that in the stages of the contract budget.
- Understand who owns the source code, and how that impacts your ability to customize and make changes to the software.
- Transition protocols and timelines for response to requests should be specified.