Wednesday, January 11, 2006

Choosing an EMR company: we decide

We decided to have a demonstration at the company's head office. All of us got together one July evening, with some of our staff, and tried the software. At the end, it seemed pretty clear that we were going to go with myNightingale.

Now came the hard work of negotiating a deal, and a Service Level Agreement (SLA). The SLA is a separate document outlining support and maintenance (such as what happens in case of catastrophic failure, how fast the company responds to requests, etc). Documents relating to the SLA can be found here, under "Contract Negotiations", and here, under "Systems Management Guidelines". Our IT lead started on this, and had some help from a lawyer. It helps if your group has a bit of money in reserve to pay for this. The FHN receives some money each month for being on-call, and we hold this in a common account. We used this to pay the lawyer, and to reimburse the IT lead physician for the time she put in. You don't have to have a lawyer review the software agreement or the SLA, but there is a lot of fine print. It is worthwhile doing.

Because of the fact that we are in 7 different offices, we decided to go with a "Configuration 3" set-up (for an explanation of configurations, please see the glossary). This means that we have a server (or main computer) at the hospital, with all of us accessing our data via broadband. There are some advantages to doing this: we contract with the hospital's IT department to do regular back-up and maintenance, and they keep a copy of all data off site (they do this as part of their regular hospital back-up procedures, so there are already processes set up for this). The EMR company works with the hospital to maintain and upgrade the server as needed. We no longer have to worry about back-up management, or database software issues.

The other FHN wanted to do this as well, and we agreed to share one single server, which cut the cost of the server hardware in half. If more FHNs decided to join us in the future, or if more physicians join our FHN, there is ample room on the server to accomodate them (this is called scalability).

The head of the hospital's IT agreed to have the server in the hospital. Having the hospital work with us is very helpful; perhaps having our server inside the hospital will help us to share our data. If a patient is in the Emergency room, or is admitted, appropriate data from their community-based chart should be available inside the hospital. Conversely, when a patient is discharged, I should have access to their hospital data.

We had to solve the problem of having non-FHN physicians on the server as well. If a physician has data on a different server, you have to log out and log back in to see their patients. That would not work very well in my office, where I am a FHN member, and my partner is not; my staff would have to continually log out and log in to switch between us. We had to get permission from OntarioMD to have non FHN physicians on our server, which they granted.

We were now ready for final negotiations. It was September.


No comments: