Before jumping onto the proverbial EMR/EHR (electronic medical records/electronic health records) bandwagon, it is important to look at the total picture. The place to begin would be to examine your motives for thinking that it is time to convert over to electronic medical records. Perhaps asking yourself whether you want to improve patient care or the efficiency of the office, or whether you want to make more money or the fact that you want to go home earlier might be factors in establishing your goals of implementing the electronic Medical Records system at your practice.

There are five basic areas of requirements to consider when developing the list of practice requirements:

1. Software functionality - how does the EMR software handle different workflow and "data flow" requirements such as billing, scheduling, clinical charting, prescription writing, referrals, recall, reminders, etc.?
2. Data standards – how is data captured, e.g., a mix of codified and free-text? What coding systems are used e.g., ICD, SNOMED, ICPC, and DSM?
3. System interoperability – does it communicate with other systems as required (e.g., lab, hospital, billing systems, provincial or regional registries such as pharmacy, chronic disease management or public health registries)?
4. Technical infrastructure – how does it provide for security, multi-user access, multiple user roles, remote access, database options, client-server or application service provider (ASP), etc.?
5. Legislative and policy standards – how does it provide for privacy, medico-legal data retention and audit requirements, etc.?

Jurisdiction-Specific Requirements
Your jurisdiction (e.g., provincial Ministry of Health or regional health authority) may have standards or requirements in any or all of the five areas outlined above. The list of questions to consider when contacting your jurisdiction can assist you to determine what, if any, support or resources are available to help the practice with EMR planning and implementation.

Practice-based Requirements
In addition to any jurisdiction-specific standards and the practice's specific goals, defining practice requirements should include consideration of characteristics that make it unique. Some sample questions for consideration are:

1. Is the practice multi-disciplinary? What types of providers are parts of your team? What unique requirements, if any, does this introduce, e.g., does the software support care plans? How much work do you need to do with your practice team to be sure that everyone's needs are addressed? E.g., clinically? Administratively? Do all members of your team use the same clinical coding standards? Do different members of the team have different billing requirements or administrative reporting requirements?

2. Is the practice in a single clinic location or are providers in multiple locations? Do you require access from more than one location? E.g., clinic, office, home, hospital, etc.? How will the EMR software support these needs? How will these needs affect your hardware and network choices?

3. If the practice is rural, is there high-speed Internet access available? Will this limit your choice of vendors between ASP (Internet based) and local (on-site) solutions? If your jurisdiction offers EMR support or standards, do they have recommendations for how best to obtain Internet access?

4. What specific interoperability requirements do you have with other systems - for instance, local labs, clinics, hospitals, provincial and regional public health/disease registries, private and public billing systems? Your jurisdiction may have developed interoperability standards for some systems, but not necessarily for all.

5. Does the practice have any specific reporting requirements to the Ministry or other organizations, related to monitoring patient health outcomes, for specific patient populations, or for provider self-audit?

EMR Vendor Selection

With so many variations in feature and functions of the EMR products existing, the question of technical proficiencies needs to be addressed. If the product is too technically advanced for the user full use of its capabilities may not be possible and this would result in paying more for more than is required and not getting the benefits of a good return on your investment. This is why matching up the practice with the right EMR is so critical.

No two practices are identical, so choosing an "off the shelf" EMR application vendor will introduce costly shortcomings in the effectiveness of its use. Almost all practices use some type of EMR application and Practice management Solution. Most Vendors provide complete solutions that are actually well interfaced individual applications. These have their own databases and data communication is via interfaces. This has been the cause of widespread concern because duplicity of the data entered and the chances of incorrect or forgotten details occurring. Savvy vendors tightly integrate the two there by ensuring that you get the benefit of the seamless workflow.

Ask the right questions when you interview the EMR Vendors: Before interviewing the EMR Vendor you must spend time researching on EMR products and trying to understand which one best suits your practice. A set of questions must be prepared well in advance before you meet the vendor.

1. what is the cost per physician license?
2. Do you have any existing clients in our specialty?
3. Does your system come pre-loaded with templates for my specialty?
4. Is your company the developers of the software or is it re-branded from another vendor?
5. Is your system client/server based or ASP based?
6. Does your system include practice management software?
7. How many clients does your company have?
8. Is your system HL7 compliant?
9. Is your system following HIPAA rules?
10. How long has your company been in business?
11. Is your development done overseas?
12. Is support done overseas?
13. How often is the software updated?

As you meet more clients you will learn more.
Most importantly if the EMR vendor promises customization or enhancements to features that will suit your needs get it in writing beforehand and add it to the contract. Remember, if it is not in writing, it doesn't exist.

The purpose of a RFP is to document requirements and expectations (e.g., functionality, support, training, interoperability, price, timing constraints, and vendor reputation), so that vendors can respond in a standardized way that makes it easier to compare the responses.
The most preliminary step in the decision making process, a request for proposal is sent to a set of short-listed Vendors.

Electronic Medical Record Support

A common saying in the Software Industry best showcases the importance of support: "Clients buy on features and leave because of the lack of Support". While interviewing the EMR Vendor, be sure to check references asking about technical support. What is the maximum "on hold" time before your telephone call is answered? Do you get an issue tracking service, which allows you to track online the status of reported issues? What is the time frame involved with regard to the resolution of issues raised?

Both models have advantages and disadvantages. Lets explore the advantages and disadvantages of each model so that you'll be able to make an educated decision when choosing the right EMR for your practice.

The Web Based EMR is a remotely hosted software system accessed via an Internet web browser.
The Client/Server EMR model on the other hand is much faster and depending on the number of patients and the size of the practice you might want to verify whether you can justify the vital seconds that are spent everyday waiting for data to transfer over the internet in a web based model especially during the peak traffic hours of internet usage.

Final vendor selection should include input from your office personnel. Will their lives become simpler in not having to file or track down the paper chart; or will they loose their job? The last being a major concern among most staff members. Studies have shown that involving the staff members in the selection process can help in the success of its implementation.