The ABCs of Building an RFP for an HIE

For an organization looking to build a health information exchange (HIE), a solid request for proposal (RFP) is vital for garnering accurate vendor proposals and a realistic estimation of costs. The RFP also is instrumental in honing technology and business requirements for all stakeholders before inviting vendors in.

What belongs in an HIE RFP? Specifics vary, but the best RFPs include:

• Specifications based on extensive input from stakeholders
• A clear vision of the tasks the HIE will perform
• Well-defined technical expectations
• Maintenance and upgrade needs
• And be sure to include that the vendor must be cooperative and roll with technological and administrative changes.

‘The ability to connect’

In October 2009, when the West Virginia Health Information Network released its RFP for a statewide HIE platform, “we were looking at the ability to connect with a number of healthcare providers throughout the state and certainly to connect the provider community and insurance companies, along with hospitals,” says Dennis Belter, CIO of the network.

Connecting with state registries also was important, says Belter. “We wanted to be able to look at things like public health and immunization,” he notes. 

The RFP results? Twelve companies submitted proposals, 11 were considered in the first round of evaluations and five were selected to demonstrate their capabilities before a group of stakeholders. The group hopes to name two finalists after the vendor demonstrations are complete, then move into negotiations and select a final vendor this month.

“We are planning an implementation for the fall, with a plan of going live sometime mid- to late fall,” Belter says.

In the beginning, the network determined that connectivity requirements and technical specifications would be the central components of the RFP, Belter says. “We were aiming for those companies that had been involved in other statewide HIEs or ... those that had been involved in putting together community information networks or regional health information networks.”

To develop its RFP, the network enlisted a consulting firm, a physician advisory group, and Functionality, Data Standards, Privacy and Security, and Technology task force groups totaling 60 stakeholders from across the state. The groups also were charged with ensuring that the RFP was responsive to the Office of the National Coordinator for Health Technology (ONC) requirements around meaningful use. Hospitals and government agencies throughout the state were contacted for input as part of the effort.

Twelve companies responded to the RFP, and 11 were found to have met the RFP’s minimum guidelines, Belter says. Those vendors were entered into a “pretty extensive scoring process,” that focused on technical capabilities, functionality, and implementation and training sections.

Five vendors emerged from this process, and moved on to the next round—full-day product demos for a group of 20 to 25 stakeholders, representing physicians, hospitals and state agency representatives, based on scripts provided by the evaluation group, Belter says. “We put together a whole new scoring structure, so the vendors who made it through the scoring process all started out at square one again.”

Making the Cut

Here are four things that every RFP should include, but are often overlooked in the development process. Flexibility. With healthcare reform and meaningful use requirements likely to change over time, it is important to focus on flexibility throughout the process. “We put a lot more in the RFP, so we would have more of our bases covered,” says West Virginia Health Information Network CIO Dennis Belter. Expertise. RFPs should be tailored to attract vendors that have experience with the organization’s particular type of HIE, and will be “more of a partner than just a vendor,” Belter advises. Stakeholder involvement. In order for the eventual implementation of an HIE to be successful,  “there needs to be a very significant community physician engagement process, in any selection of system that we expect multiple physicians to use,” says Todd Rowland, MD, executive director of HealthLINC. Business specifics. “People should go into these efforts with a good business case in mind,” says Holt Anderson, executive director of the North Carolina Healthcare Information and Communications Alliance (NCHICA). The facility or group must determine “why are we doing this?” he says.

Regional approach

One RFP won’t fit all; each community involved follows a different pathway to HIE selection and implementation, says Todd Rowland, MD, executive director of HealthLINC, an HIE in Southern Indiana.

In the case of HealthLINC, the process “was lengthy, and required significant community physician engagement, as would any selection of a system that we expected multiple physicians to use,” Rowland says.

Committees had to be developed for the creation of a RFP that would include multiple organizations and stakeholders, including tech support staff from hospitals, large physician practices and radiology facilities, Rowland says. “With multiple organizations weighing in, we had a pretty good level of participation for that process,” he says.

A detailed RFP was developed and deployed in 2006. “We received eight responses [and] were able to narrow the choices to six immediately, because two of the vendors did not meet basic requirements that were seen as mission-critical,” recalls Rowland. These included a requirement to work with HL7 codes. If the organization were creating an RFP today, prospective vendors’ products would need to be compatible with additional standards, such as Continuity of Care Document (CCD) and RxNorm, he adds.

“We also wanted to know if [the vendors] had experience with scaling to a community of our size, and we wanted to [know] the number of deployed sites,” he says. This was a challenge in 2006, because there was much less information regarding HIE successes and failures than is available today. “Many people didn’t know what HIE was at the time,” he notes. “We had really excellent consultants, however, who understood how this related to any other community process or technology, and helped us through this process.”

Technical assessment was a big part of the RFP process: “We wanted to make sure a lot of options presented to the larger medical community would be technologically supportable,” he says. Two vendors emerged from the technical assessment phase.

The final evaluation was “a two-day process where we had 65 people involved, including a technical group, physicians, practice administrators and hospital leaders, all having the opportunity to see the different software systems and ask their different sets of questions.”

Participants then completed a formal survey. “We basically spent two full days running the vendors through the paces, and in that process it was clear that the Axolotl/Healthbridge combination came out of that process for us,” he says. 

A Gateway RFP

On February, the North Carolina Healthcare Information and Communications Alliance (NCHICA) released an RFP for the NCHICA Gateway, a platform that would connect the data link of the Western North Carolina Health Network—a health information exchange organization that links 16 hospitals—to the Nationwide Health information Network (NHIN).

Throughout the RFP process, a group of contractors led by Andrew Weniger, project manager of NCHICA, the agency “attempted to give as much information as they could to get a tight group of proposals in return,” says Holt Anderson, executive director of the alliance.

The RFP included technology requirements, implementation and testing provisions, as well as operational and maintenance conditions. However, “I think sometimes we focus too much on the technical side, so we spent approximately half our time on policies and procedures,” says Anderson.

Ongoing upgrades were a key requirement for the Gateway, he says. “We needed to know what the gateway would be beyond just the implementation and first phase. We had to know what it would take to keep it running.” In addition, the RFP included the requirement that the Gateway support all nationally recognized data code sets and exchange standards, including HL7, X12, DICOM and NCPDP.

“We had a lot of interest, and nine vendor proposals,” recalls Anderson. This group was whittled to three and eventually, Mirth was selected. Testing is now under way, with actual production slated for early fall.