Once you have selected your EHR-S product and vendor/partner, you can begin preparing for the contract phase. You will need to do a few key things first:
- Hire an experienced software contracts attorney. An EHR-S is a big, costly, important, long term decision. The attorney fees can be well worth the investment! I know many of you have attorneys on your board, but before you go with pro bono services, assure you are working with someone who has experience writing and negotiating contract for enterprise software with the software developer. I have seen and heard too many horror stories when things go wrong and the contact didn't cover it.
- Discuss with your selected vendor whether they are open to using your agreement or must you use their existing standard agreement? If so, get a copy. Some vendors will not work with any other contract but their own, others are happy to use your model agreement, but will charge you their legal fees to do so. Be aware!
- Begin creating the necessary exhibits.
Prepare exhibits for.........
- Deliverables:
- Client & claims databases for conversion - which databases do you want converted into the new EHR-S? Definitely the DMH LAC IS SIFT/LE Extract, what else?
- Payors and funding sources / rules - which payors do you expect the system to include in billing? what payors' rules do you expect to be configured?
- Services (by program, payor, credentials, role, code, usual and customary fee, contract fee) - not critical for the contract, but not a bad idea to include this list if you expect the vendor to do the set-up for it.
- Forms & reports for configuration / programming - an inventory list of all forms and reports you expect to be in the system at launch, identifying which are payor/audit required and gather samples of each.
- User list (name, role, credentials, NPI, skills, Supervisor(s), programs, sites, teams, forms to be co-signed). For the contract you really only need the total # of users, but developing this list may change your numbers and you will need this for implementation anyway.
- Testing & Training deliverables - some of these will be your responsibility and some you will want the vendor to support. If you are using an ASP solution, the responsibilities will be a bit different than if you self-host. Think about how you will test the revisions and fixes delivered on an ongoing basis. Plan for: a testing database, a test environment (clients, providers, data), test cases (daily workflow, scenarios that are complex, have failed in the past, are high volume tasks), a training database, a training environment (clients, providers, data), training cases /scenarios.
If you are using an ASP, be sure to contract for the testing and training databases, and your full control of each.
- The Work Plan / Timeline - You will also want to include a Work plan with timeline, milestones, and corresponding payments. The work plan or schedule should be included at a high level, to assure that there are some timeline commitments whether a detailed schedule is ever developed or not. Ideally you should collaborate on a detailed schedule once all the requirements are completely understood and the project is staffed, then replace the timeline in the contract with this detailed one. If neither party ever agrees to a detailed schedule, at least you have the high level timeline in the agreement.
- Performance standards - ask the vendor if they have standards already. Usually they do, but if not, create your own. They should include several levels of problem definitions and the response time and fix time they will commit to for each. For example, a Critical problem means it is severely impacting your business and their is no satisfactory work around. How long will it take them to respond/begin working on the resolution? How long will it take them to fix it? Don't be surprised if they won't commit to a fix timeline, but be sure to have resource commitments and next steps for each level. Committing to fix an unknown problem is a bit tricky.
- RFP / RFI & Responses - you should include all the document you issued as part of your Request for Information (RFI) and Request for Proposal (RFP), as well as the vendors Responses. Keep track of all documents requesting vendor/product information during the formal RFI/RFP process and label them as such. Use document version control.
Other things to consider when contracting:
- Cost controls, e.g. cap on annual cost increases, per user rates, and hourly programming fees.
- Vendor will obtain and maintain the CCHIT certification for Behavioral Healthcare.
- Vendor maintains significant state and county compliance / change management, while agency can control regular change management tasks to remain in compliance with existing and new payors as necessary.
- Agency has some control over ASP deployment timing in order to assure adequate training and planning takes place.
Contract Terminology:
Take some time and create terms and definitions that you plan to use throughout the document, particularly the ones you will use after launch. For example:
- Enhancement vs. Paid Enhancement vs. Custom Programming
- System vs. Application vs. Database vs. Software
- Version vs. Release vs. Upgrade
- Form vs. Report vs. Screen
- Data vs. Client Data vs. Provider Data vs. Claim Data
- Go-Live / Launch – when do you make your final payment?
Be sure you and the vendor understand each term and how it is being used. Use terms that are simple and commonly used in your organization and with the vendor.
Good Luck!
by Keely McGeehan, Sahara Management Solutions, Inc.
No comments:
Post a Comment