Selecting Technologies for an EHR
The task of choosing technologies for an organization varies greatly from doing it for an electronic health record (EHR). The tasks themselves are similar, but the focus, priorities and evaluative criteria for selecting technologies are not. You need to define the community to be served by the EHR, understand existing assets to build upon, figure out how it would be funded and determine the interoperability requirements. Remember, for most technologies, the software is important, but not as important as the direction and commitment for continued development and how the solution gets implemented.
Define the Goal
Defining the goal is not always as simple as it may sounds.What problem needs to be solved? What community will be served? Consider the players who will benefit from the technologies being evaluated:
- A group of providers, payers and other interested parties in the community such as a regional health information organization (RHIO) to enable clinical and demographic data exchange and linkages;
- A physician group with an eye toward linking to consumers and other community players at the right time; and
- A hospital system (advanced clinical system including computerized physician order entry) considering linking to EHRs, consumers and other community players at the right time.
There are many other combinations and possibilities. The processes that can be automated and the data/standard requirements are vastly different depending on the defined goals and the players who stand to benefit.
Define Commitment
Who will pay for this? Who will benefit? The success of any technology initiative depends on the commitment of representative key players within an organization or community, so testing the readiness of constituents is a good idea. Early participation may also reduce resistance toward using technology once it is up and running. Physicians, nurses and other key clinicians must be heavily represented on the technology selection team. Also, involve key technical professionals to weigh in on the right mix of custom versus off-the-shelf solutions.
Understand the Vendor Landscape
If an organization is a fledgling RHIO, or a component of one, no off-the-shelf software package will work today. In fact, few vendors are even aligned with the concept of a shared EHR and lack the orientation toward developing community standards, sharing ideas and collaborating to achieve the necessary connectivity. The vendors are actually the integrators in todays market.
For physician-based organizations, there are a number of well- developed choices and some up-and-comers to evaluate. Likewise, hospital-based organizations also have a number of established software options. Many sources of market assessment data are available through KLAS, consulting firms and networking. It is absolutely critical to plan for the workflow and data flow required by the eventual EHR. Otherwise the end result will be mixed purposes and a zillion silos of data.
Also realize that no single vendor can solve all the clinical data exchange riddles. The requirements are immense (see Figure 1).
So do the homework before approaching vendors. Determine up front if the EHR will grow from the perspective of hospital-based systems, physician group-based systems, or payer-based systems.
Evaluate Assets
What already exists and what standards are in place? What investments have already been made? Before doing outside research, understand and document current standards and architectures embraced within the community to be served. At this step, organizations must assess their own level of willingness to work with other groups. Because collaboration is so critical to the overall EHR initiative, its important to determine up front whether the requisite information sharing can occur.
Address technical concerns, such as existing platforms and opportunities for interoperability. In addition, leverage HIPAA, e-prescribing and patient safety initiatives already in place to get closer to a connected EHR.
Existing health records can also be leveraged by populating the local EHR database with information from RHIOs or the National Health Information Network (NHIN). It should be noted however, that, although tapping into an existing RHIO facilitates the automation of clinical processes, it will still require new EHR functionality.
Determine EHR Workflow Requirements
Be sure to look at the supportive technologies through the lens of workflow and data requirements. Decide who will have access to information, what roles these players will have and how these roles affect workflow.
To get started, evaluate collaboration efforts such as regional and community-based health information organizations and networks. Players include large health plans, hospitals, physician groups, healthcare IT suppliers, public health organizations and the government. These groups come together to explore challenges and strategies related to healthcare IT and health information exchange. There are similar state and national initiatives, such as the NHIN.
Evaluating workflow requirements includes deciding who will maintain EHR data and what types of information will result, such as reference lab data, consultant notes, prescription records, immunization and allergy records, and hospital data (surgery notes, discharge notes, etc.).
Also determine how patients and consumers will be identified, such as by social security number, account number or other specialized ID. In addition, decide which clinical processes will be enabled by the EHR and at what point in time.
For legal purposes, the workflow plan must also incorporate a process for synchronizing to a legal record of care. Consumers must also be considered as part of the workflow. Work with collaboration partners to decide how a constituents health status information will be updated and made available.
Determine EHR Technology Requirements
Next evaluate internal technology requirements. Consider the type of proposed infrastructure, including the network, portal opportunities, server utilities and who can access the system for security purposes.
Interconnectivity among different record-keeping systems must also be reconciled. For example, existing clinical data repositories, EHRs and computerized patient records must somehow coexist within the framework of the larger EHR initiative. E-prescribing systems and electronic payer processes must also fit into this scheme.
In addition, determine what type of user interface is appropriate for each constituent, depending upon individual needs and devices being used to access data. For example, a customer-facing portal varies greatly from a physician portal. Its also possible that Web screen access through the NHIN could allow authorized users to view data with little or no need to involve an EHR system vendor. This must be considered before talking to vendors.
Assess Solutions
Organizations and communities that have addressed the above concerns are ready to begin assessing technology choices. Figure 2 is a simple model for evaluating, assessing and confirming the correct choice.
The key questions in this process must include:
- Which work processes should be technology enabled?
- What are the critical business functions to support? Give prominence to these requirements in developing the request for information and request for proposal.
- Using the 80/20 rule, what are the key drivers of functionality? (Dont let requirements become littered with details).
- What risks must be addressed (e.g., financial stability, how new the vendor technology is and whether it is proven)? Ask for the vendors history and product development track record and request a list of satisfied customers.
- How does the technology actually fit with outlined needs? A fit test provides an opportunity to really look at the technology in depth. Develop workflow-based scripts and conduct demonstration sessions to showcase the tools in action.
- What will this cost? Create an apples to apples view of the cost differences. Look at the total cost of ownership, not just up-front costs.
- How will this be accomplished? Create an action plan around project implementation.
First, break the project into different phases to create manageable sections. Also outline resource and key integration requirements during this planning stage. Importantly, compile and summarize a list of benefits to make the implementation compelling. Finally, draft a charter that addresses scope, governance and the multiconstituent roles and responsibilities.
The process approach for evaluating and selecting an EHR conceptually is in Figure 3.
Summary
The evaluation and selection process will depend on what players are trying to accomplish and where they are coming from. Focus on the functions and features of possible solutions, but first make sure there is an agreed-upon, balanced scorecard of criteria for selection. Use the evaluation process to achieve buy-in of those who will be affected, but avoid the proverbial analysis paralysis. In most cases, how something gets implemented is more important than what gets implemented.
