Ask the right questions in requests for proposals.
“Finding the right software to meet financial needs can be one of the greatest business investments,” says Pamela Jodock, senior director, health business solutions, Healthcare Information and Management Systems Society (HIMSS).
Yet when it comes to developing requests for proposals (RFPs) for cost accounting, decision support, or business intelligence applications, “There are a lot of opportunities for missteps,” she says. “One of the biggest mistakes leaders can make is not thinking through their specific needs before they begin to shop for a solution. It is critical for the provider to understand what the organization’s current and future requirements are within each functional department before they begin their search.”
Architecture and Functionality
Before issuing a financial software RFP, Jodock recommends creating a vision and scope document that compares functionality and feature “must haves,” with “nice to haves.” The document also should detail how information is shared between internal and external business partners, including transaction volumes and systems that will need to integrate.
When crafting the actual RFP, leaders should include the following questions to help them better understand the design and architecture of the financial software:
- How long has the software been on the market?
- How often is the software updated, and who pays for these patches (the client or the vendor)?
- Can the software be integrated with the current network?
Receiving a simple “yes” to the last question may be cause for concern. Jodock advises asking for details regarding how the vendor plans to integrate its software with the organization’s existing systems. “Being able to simply plug your system into another system doesn’t make them interoperable, so you need to understand that integration piece,” she says. This is especially important for organizations that are engaged in merger and acquisition (M&A) activity and may be juggling multiple clinical and financial solutions across the enterprise.
When reviewing software designed to help organizations succeed under alternative payment models, it is especially important for leaders to understand the software’s level of sophistication, Jodock says. Until recently, financial and clinical software could operate independently without the need for much integration. But that is quickly changing as more organizations engage in value-based payment models where at least some portion of payment hinges on clinical quality measures. “We are dealing with models of payment that our legacy financial systems never contemplated and aren’t able to support,” Jodock says.
The RFP process can also help leaders determine whether the software is user-friendly. For example, current vendor clients can provide references and share functionality, training, and support information.
Considering Privacy and Security
“At times, there can be very significant vulnerabilities present within either the software platform itself or a third-party component, such as a software library that the software program relies upon,” says Lee Kim, JD, FHIMSS, director, privacy and security, HIMSS, Arlington, Va.
The following are some questions that one should consider including in the RFP that can help leaders understand the software and associated risks:
- Was this software exclusively developed by the vendor?
- If not, what third-party components did the vendor use?
- Are any components sublicensed?
With this information in hand, the security team can search the National Institute of Standards and Technology (NIST) vulnerability database (nvd.nist.gov) to determine potential risks, such as glitches that would allow low privilege users to view data or issues that would allow hackers to “crash” the software. Working with the finance team, security leaders also will want to understand the relative complexity of the software because complex platforms may be subject to errors in logic or programming. For example, as a software development team is rushing to meet a deadline, they may inadvertently leave a “back door” in the software, which could be accessed by unauthorized third parties, Kim says.
To assess potential privacy risks, finance leaders need to understand who holds the data in a supplier relationship, Kim says. Consider asking the following questions in an RFP:
- Where is the data hosted, and who controls it?
- If the data is encrypted, who holds the key?
- Who else may have administrative access to the data?
- What happens to the data when the supplier relationship ends (e.g., is the data returned or destroyed)?
- What procedures are in place if a data breach occurs?
- Does the vendor want rights to use de-identified data for other purposes, such as developing other software?
Heeding Lessons Learned
Following are additional suggestions from Jodock and Kim on developing and evaluating RFPs for financial software.
Consider a request for information (RFI). For new types of financial software, Kim suggests starting with an RFI prior to submitting an RFP. “The RFI gives vendors and consultants the opportunity to understand the scope of what you are looking for, including technical requirements, timeframes, and expectations,” she says. With RFIs, the project scope and associated logistics can be set forth. Based upon the RFI responses, leaders may identify an array of potential candidates for the project. RFIs are typically used for informational purposes.
Customize RFPs. “Don’t think RFPs are just boilerplate,” Kim says. RFPs can vary in size and scope, from skinny, streamlined documents to those that exceed 100 pages. Whatever approach an organization takes, leaders should make the RFP their own by involving key stakeholders in the RFP development and evaluation process. This may include finance, accounting, legal, and IT leaders.
Designate a project manager. This can be an internal or external resource who will oversee the research and implementation of the new software, Jodock says. Project managers should have a thorough understanding of the business and culture as well as time to commit to projects without compromising other responsibilities. They also should be well versed in systems and technology.
Allow time to evaluate proposals. Build realistic timelines, so vendors can respond thoroughly to RFPs and teams can review proposals carefully.
Don’t allow vendors to “sell” their solutions if they are not good fits. Jodock urges leaders to look beneath the surface when faced with glitzy presentations from software vendors. “You need to measure the capabilities and features against your must-have and nice-to-have lists,” she says. Leaders should pay particular attention to reporting capabilities and interoperability, which may get overlooked during the selection process.
Overcome language barriers. Jodock urges finance leaders to recognize that they may interpret a vendor proposal differently from their IT colleagues. Regular multidisciplinary meetings can help reduce potential disconnects.
Make sure the platform has room to grow. The software should scale with the organization as it grows,” Jodock says.
Don’t assume vendors understand each individual business. Although a vendor may have a large market share and be entrenched within the healthcare industry, it may not recognize what makes each organization unique, Jodock says. She suggests that vendors meet with end users to understand their needs.
Thinking Beyond the Purchase
“Organizations need to think about the big picture, not just the initial purchase,” Jodock says. Beyond purchasing the right platform, leaders should know who will oversee the conversion and entry of the data into the new system. Will finance and IT leaders handle this in house or will the vendor take charge?
Leaders also should ask about vendor training. Will the vendor train all users or only super-users, and who will train others in the organization? Understanding available support and how long it will last after implementation is essential.
To gain the greatest ROI, organizations should be prepared to change business practices. “Chances are, the business processes you have in place are going to be disrupted by the new software, and that’s not a bad thing,” Jodock says. “If you’re not intentional about making sure your processes and software work together, you can create unnecessary frustration and inefficiencies internally and with your business partners.”
Laura Ramos Hegwer is a freelance writer and editor based in Lake Bluff, Ill., and a member of HFMA’s First Illinois Chapter.
Interviewed for this article:
Pamela Jodock is senior director, health business solutions, Healthcare Information and Management Systems Society.
Lee Kim, JD, FHIMSS, is director, privacy and security, HIMSS, Arlington, Va.
