Health IT has been put back into the forefront of the Obama national health care initiative, in part because of financial incentives built into the ARRA for health care providers that implement and meaningfully use a health technology system in the next few years. The cost savings are premised in part on the success of the installation and implementation of the information system to be used by health care providers. This article will focus on some of the details of implementing an electronic health records system, along with some of the pitfalls that can keep a project from being completed successfully.
The End Goal is Meaningful Use
In order to receive reimbursement from the Medicare or Medicaid program, the ARRA requires that a provider demonstrate meaningful use of the system, connection to a health data exchange, and submission of data of clinical quality measures for patients at the practice. (See my blog for more details here) Reaching these goals goes beyond the mere technical installation of some computer system; meaningful use in particular will likely require health care providers to show that they actually use the computer system in managing patient care, reducing errors, and improving health outcomes for individual patients.
Getting there requires effective planning for the project and a productive implementation process.
The good news for providers who want to implement an electronic health record is that: (a) the data a provider needs to effectively see patients will be available when you need it (no more lost chart syndrome), (b) the chart documentation will support the diagnosis and E&M codes billed to the insurer, (c) electronic health records can be tightly integrated with a practice management system to reduce data entry errors and improve billing, (d) most electronic health records will make clinical or mandated reporting easier as compared to paper charts, (e) lab results can be electronically imported into the electronic health record from major lab providers, (f) improved E&M coding can lead to better reimbursement, and (g) an electronic health record investment can be viewed by your staff as an investment in them, leading to higher staff retention rates and satisfaction. But there is a cost to achieving these benefits.
For one, some of the office workflows for handling patient care may need to be modified or adjusted to incorporate the electronic health record. Some workflows that operate on paper in an office will not convert efficiently to a computer system. Forms used to process or document patient care may also need to be modified when they are converted into the electronic health record. Electronic health record installations for health care providers tend to expose workflow problems and breakdowns that require attention in implementation for the project to be successful.
Secondly, all the staff in the office will need to be computer literate, and generally, physicians and other health care providers will need to be able to use a computer effectively while examining their patients. This has become less of an issue as more doctors and other providers are trained to use a variety of computer systems at medical school, but computer literacy is still a major issue for some practices in the nation.
Third, electronic health record projects are high risk – there is a substantial chance that the project will be derailed for any number of reasons, including a lack of a process for effectively making key decisions, office politics, the capital expense to acquire computer hardware and software, and a lack of technical expertise among the implementation team, among other challenges. These can be overcome or at least mitigated by sufficient advanced planning by the organization.
And finally, most studies of electronic health record installations suggest that your practice will be in the minority of practices using an electronic health record (though there has been an improvement in the market penetration here over the last few years). This is partly because of the expense of implementing the systems, and the longer-term costs of maintaining them.
You can get there if you have a good plan.
Manage Expectations Early and Often
No, an electronic health record will not solve your workflow problems without your help. An electronic health record is not free, even if licensed under an open source software license. The data that is collected in the electronic health record is useful, but will require further technical assistance to be useful for research or analysis. Staff can’t keep doing things the same way and expect a different outcome (besides this being one definition of insanity, electronic health records are not magical beasts with wings, and magical thinking does not lead to a happy end user). Doctors won’t be able to see 50 patients per day after install if they were only able to manage 20 per day before. A project that lacks goals that are attainable will fail.
Any system project can be a victim of unreasonable or unrealistic expectations. Those leading the project need to be frank about what can be achieved and at what cost to the staff using the electronic health record. Expectations can be managed by establishing tangible goals and having a workable project plan with real milestones and a clear assessment of the resources (financial and staff time) that will be needed to reach each one. For example, implementing the electronic health record two months from purchasing it can be realistic, but only if the provider’s office is prepared to commit significant time to the planning and installation, particularly in identifying forms that need to be developed electronically and lab interfaces that need to be installed (two of the most time-expensive portions of an electronic health record implementation). The need for effective training can also not be understated – staff should not expect they can pick up use of the system in an hour or two, or learn as they go with live patients in the room.
Picking an Information System
Finding the right electronic health record is an important task and should not be left to chance. There are a lot of electronic health record vendors in the market place today with a variety of installations, history, and effectiveness. Developing a written request for proposal and requiring an objective process for evaluating responses to the RFP is essential to fairly evaluate the vendors in the market place. Sending the RFP out to 100 vendors is also not helpful, nor is having a 100 page requirements section. But your prospective partner for this project should be able to effectively respond to your RFP and explain in satisfactory detail what the options and costs are for implementing the proposed system.
Furthermore, your organization should form a search committee that is comprised of enough staff to provide meaningful input on the responses to the RFP, and to interview qualified vendors to assess for the needs of the essential practice areas. Vendors should also be able to competently demonstrate their project to the committee’s satisfaction, so that the committee can identify the best two candidates for the job.
To help encourage staff buy-in (where your facility is sufficiently large that the search committee may not represent all interests), I have also recommended that the finalists demonstrate their product to all staff, and to put the final decision to a group vote. This doesn’t work in all organizations, but the more effort you put into including the staff that use the system in the process, the more buy-in to the project you will garner, which increases the odds of a successful implementation.
Once you have identified the best candidate electronic health record, your organization should begin to examine the terms of the contract with the electronic health record vendor. Most vendors have a standard form contract that describes the terms of the relationship, particularly for ongoing support and updates to the product. These contracts are complicated and an attorney can be helpful to ensure that the contract fairly represents the relationship, costs, and promises made by the vendor along the way.
Negotiations can take some time to complete, particularly where multiple parties are involved or there are substantial costs involved. Hammering out contract details with the vendor is an important step in the planning process.
Once a vendor has been chosen, most electronic health record implementation project plans will have the following major milestones to get to a successful go live: (a) form a planning committee, (b) form a technical team, (c) review and make decisions on the requirements for the project, (d) install the server, software, and workstation software, (e) develop all required clinical content (such as electronic forms, flowsheets, and data requirements) for go live, (f) implement all interfaces for data flowing in and out of the electronic health record, (g) conversion of all charts from paper into the electronic health record, (h) staff training completed, and (i) go live with the system.
The planning committee should include the clinical departments that will be using the system, and should be designed to regularly meet up to and through the go live date. The committee should be charged with enough authority to make decisions about the project’s implementation, and should become your initial group of super-users or staff with more training about the electronic health record. Your super users should then become sources of information for the rest of the staff as they work through integrating the electronic health record into their practice.
The technical team is comprised of the IT staff that are responsible for installing the server and workstation equipment, getting the electronic health record software and database installed properly, configuring interfaces between systems, and installing any supporting network or peripheral technology. This team should regularly report to the planning committee or the project manager for the installation.
The planning committee is responsible for making the decisions about how the electronic health record will be implemented. The vendor supplying the system should regularly participate in the committee’s meetings, and generally the project manager should chair the committee. Actions and decisions of this committee should be documented and distributed to the members. In my experience, the meetings of the committee or geared toward training the members on the details of the electronic health record so that they can determine how the system should work for their departments. These meetings can be contentious as a number of people will need to agree, but in the longer term, this process helps to make sure that the project is implemented appropriately.
This committee also should be responsible for identifying project priorities. The reality is that no electronic health record implementation can go live with every request ready – there are always too many requests and not enough time to implement all of them. This committee should be prepared to identify what’s most critical and clarify these priorities to the staff involved in the installation.
In addition, this committee should be committed to be thorough and address concerns along the way with specific implementation decisions and priorities. Some decisions made early on can be very time consuming and costly to correct later.
The clinical content of the application includes the electronic forms that will be used to document care, the organization of the sections of the electronic health record that display structured data (such as lab results for a patient), and other functional areas of the electronic health record that are susceptible to modification at implementation. This development may be handled by the vendor. However, post-go live may require the provider to maintain the content developed during implementation, or be in a position to add new content. In some cases, third parties may be able to sell pre-made clinical content separately from the electronic health record vendor. All of this customization of the product requires special attention to ensure that the content developed meets user requirements and that the content is developed according to standards acceptable to standard practice.
Most electronic health records support some interfacing with other products, using a common language like HL7. If interfaces with other software or third parties is essential to the implementation, substantial lead time and attention to detail is required for these interfaces to be ready at the go live date for the project.
Some meaningful portion of the existing paper charts will need to be converted to electronic format into the electronic health record, prior to go live if at all possible. This is a very time-intensive process, and is often used as a training opportunity for users, who can be scheduled to convert specific charts as part of learning how to use the electronic health record. However, most practices have many more charts than users available to convert them, and many project planners will budget additional resources to aid in the paper conversion process.
Some practices opt to extract specific data from a paper chart into electronic format, using specialized clinical content for this purpose. Other practices may simply scan and index the paper chart documents as is into an electronic document and attach it to the chart as the chart history. Still others will do a hybrid of these two solutions.
Training is also a very important aspect of any electronic health record implementation. From my experience, up to 20 hours of training may be required for super users of the electronic health record; the minimum is about 4 hours for sufficient exposure to the basics of an electronic health record. Depending on the total staff to be trained, scheduling training classes for an organization may be a substantial time commitment. Generally the electronic health record vendor can give guidelines on the minimums for training to gain proficiency on the system. Note that no implementation’s training will end at go live; generally post go-live training and ongoing training for new staff after the system is implemented are ongoing expenses of the electronic health record.