Skip to main content

On vendor lock (or how to turn a customer to an enemy)


All looks perfect when you are in love. The person you're with seems to have all the qualities you were looking for in a partner. He is always there for you, attentive to your needs, promising to fulfill all of your wishes. But as this story goes the statistics kicks in, and you soon find yourself sitting with your friends and moan about very similar things.

When it comes to a healthy relationship between clients and suppliers it is good to follow the same advise a psychologist will give you for maintaining the relationship between you and your partner in life: have constant and open communication, align your plans together etc. But there is one very important recommendation that often escapes and is the hardest to implement and that is to keep your independence!
The advice is really relevant for all industries and is not specific to healthcare, however, when it comes to healthcare it is much easier, as a customer to lose your independence and without even noticing it. Since health organizations tend to be quite different from one another, so is the way the software are being implemented to support the processes and local systems in place. The more a health organization invests in tying a solution that meets its needs, the tighter the bondage between it and the software vendors gets. Contributing to the problem are the facts that many software are considered "mission critical" and the poor financial state of health organizations around the globe doesn't help either.




So what can be done to avoid a vendor lock? It starts with selecting your partner. On your qualification checklist you should have the ability to adjust and extend the software without requiring the vendor. This can be in the form of a solution designer editor or an SDK that you or other service providers can use. 
When building your solution it is better to adopt common practices and standards which are easier to replace, even if it means compromising on your dream solution.
Get to know your vendor clients and share your roadmap and pains on a constant basis – you will be much stronger and vocal together as a group when confronting your vendor. 
Finally, prepare to the day after from day one with a prenup. Make sure the vendor will be committed to assist in migrating the data to a new software if you decide to break apart.

And always remember – a true love comes when you know you can do without it!

Comments

Popular posts from this blog

Clinical data warehouses: Sometimes it's worth being lazy

If you are a health organization you probably have or thinking of having a clinical data warehouse. A Clinical Data Warehouse (CDW), sometimes called Clinical Data Repository (CDR), is a database that consolidates data from a variety of clinical sources to form a unified view of a the data for various purposes. Typical data types which are often found within a CDW include: clinical laboratory test results, vital signs, patient demographics, administered meds, hospital admissions, ICD-9 codes and more. Developing and sustaining an effective CDW operations unit is a substantial effort and long-term commitment. The main challenge in designing a CDW is defining its scope and the use cases it should support. In theory a CDW can serve as a basis for reporting, studying and planning. The use case that is often mentioned in relate to CDW is supporting clinical trials. This would allow for researchers to have all the information from a study in one place as well as let other researchers benefit

The big battle: Best of breed vs One stop shop

The world of economics has decided on this debate a long time ago: monopolies are bad, diversity is good. No matter what a monopoly promises, you can rest assure that over time the lack of competition will cause prices to go up and quality to go down. When it comes to healthcare IT, however, there is one unique factor that flips the coin – interoperability. Despite various attempts the healthcare industry has yet to solve the interoperability challenge in a satisfactory manner which will enable a full continuum of care across different health information systems within a health delivery organization. Taking a common scenario of prescribing a medication order in theatres using a surgical system to be later administered in a ward requires significant investment to achieve, even using the modern Fast Health Interoperability Resource (FHIR) protocol. The investment required to streamline the data flow across systems raise in an exponential order with every new system that is thrown to t

Are we ready for a Cloud First hospital?

I will start this article by defining what I mean by the term a Cloud First hospital. The term cloud has been a buzz word in the past decade which led many organizations to declare their support for the cloud, sometime without understanding its true meaning. For the purpose of this article I am proposing a simple test to decide whether an organization is a cloud first or not. If you are software vendor you must have an IT department which directly in charge of the system up-time at your clients sites. If you are a health organization then you should never have visited the data center where your data resides. A Cloud First hospital is one which more than 50% of its systems reside in data center that none of its staff members ever visited or not even sure where they are. According to a recent survey by Datica, in the US only 17.7 percent of the respondents say they work with healthcare organizations that have more than 50% of the existing software infrastructure remotely hosted or