One of the cornerstones of our e-Health future is the enabling technology infrastructure (including all of the communications, software, hardware and database technologies) that will combine to deliver the e-Health solutions we will require. As with the procurement and delivery of any cornerstone, it is important to turn our attention to some of the most common and important causes for e-Health technology procurement failure, and how to avoid those pitfalls.
Although the procurement of important (and often very expensive) e-Health technology infrastructure projects have very different structures and risks associated with them, they share one of the most common procurement mistakes – the frequent failure to fully and clearly define the procured technology in terms of its detailed operational, functional and technical specifications in the procurement contract.
Those "specs" might include information that the sales or marketing representatives have provided to the buyer, and they might also include end-result requirements that could be related to either administrative or patient outcomes. And remember, in the e-Health world of "many contributions toward solution" those specifications should also include connectivity, interoperability and compatibility requirements for all of the other necessary solution "puzzle pieces" that are required. That may also require additional due diligence on your part.
The specifications should certainly include those published anywhere by the manufacturer, as well as the applicable User Manual and other published technical information. Without such details, you will not be able to claim under the warranty, nor will you have the empirical information you need to acceptance test the technology before you fully pay for it.
The technology's requirements can take many forms, including diagrams, flow charts, and other requirements that are specified by the buyer and agreed to in the procurement contract, whether provided by previous buyers of the technology who have had problems, or as taken directly from the governing RFP, or as otherwise introduced in the contract negotiation process.
Also, there are many other technology compliance duties that externally flow from other sources, such as healthcare standards bodies (including Canada's Ministry of Health), the many related publications of the Canadian Institute of Chartered Accountants, and the growing body of federal and provincial compliance legislation and regulations, including those related to personal information, privacy and medical records protection.
Another of the most serious technology procurement mistakes lies in the procurement process itself. All too frequently, a health enterprise's competitive tendering documentation (whether an RFP or otherwise) is formulated, prepared and actually issued long before it has been subjected to either a best practice or specialized legal review. In a very real way, such technology procurement contracts are too often drafted as "a contract tail" that is intended to "wag the procurement dog" – which is a certain recipe for difficult contract negotiations.
Once such "pro forma" documentation has left the building, it is often too late to require adherence to any of the best technology procurement and contracting practices that weren't originally included in that documentation. If omitted, many fundamental aspects of the procurement may simply be too hard to reintroduce into the process, such as: was an RFP issued when only the issuance of an RFQ or RFI was needed; what are the most important technical, commercial and legal terms and conditions of the procurement; what product or service pitfalls were discovered in the course of the buyer's due diligence research that must now be preventatively addressed; what is the process by which the contract will be proposed, formulated, negotiated and settled; have those terms been organized into graduated categories of " requested", "preferred" and " mandatory" importance for the buyer; has the procurement process itself been contractually manifest (or, as one recent RFP mistakenly did, does it disclaim that the RFP created any contractual obligations concerning the RFP's otherwise stipulated rules of procurement conduct); or, ensured that all "upstream" sources of procurement requirements have been addressed (e.g., insurance contract restrictions, previous audit recommendations, or from funding contribution agreements.)
Another one of the most serious and common causes of technology procurement failure in the e-Health sector is directly related to the previous two pitfalls. Far too frequently, healthcare enterprises rush to procure high-tech goods or services far too prematurely and well before they fully understand how that piece of technology truly fits into the overall solution and even the business case for the desired procurement transaction.
Without a detailed business case, and far before they know exactly what those goods or services are, many e-Health enterprises embark on an ill fated process of procurement with a "needed it yesterday, but will decide what it is tomorrow" attitude.
In my experience, the only safe way to move that process forward is to separate such a procurement into three stages: the business case creation phase; the design, define, and describe phase; and, the build or buy phase.
Unlike the Agile Software Development methodology, where buyers decide what it is they are building as they proceed, the most successful technology procurements that I know of rely on the far more boring house construction model – where you cannot start to build a house until you have a blueprint of that house's design and specs ... maybe not all of the countertop and furniture detail, but certainly all of the material aspects of the house.
Originally published in the 2nd Quarter, HIM&CC
The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.
