Skip to main content

Home grown and die slow systems

The atmosphere got tensed as the meeting went on. We were all started feeling a bit uncomfortable. The meeting took place at headquarters of one of the prestige hospitals in the US. A hospital which constantly ranked in the top 10 best hospitals in the world. A drop of sweat sprout on the brow of the IT executive which was leading the meeting. The participants nodded their heads as they realized that despite the massive investments in developing their home grown systems over the years they are lacking some basic features which typically found in commercially available products, and many of the modules in used are becoming old and need to be replaced.

That same realization repeated itself in similar discussions I had with other health organizations around the globe which took the "home grown" path. It seems there was a paradox between how wealthy is the organization and how poor its IT systems are.



Selecting a commercially available product is a frustrating task. Typically, you'll find yourself compromising on the functions you have in mind. The integration with existing systems is a mess. The overall cost exceeds the budget you were given, and at the end of the day you are likely to get screams from the users claiming the system is too complex and requires changing their way of doing things to be compatible with the new system.

In light of those reasons developing your own software sounds very tempting, especially if your organization has the money to afford it.
Another reason for the paradox is that wealthy organizations are usually very innovative. The health organizations I mentioned were all pioneers in using electronic medical record for delivering care. Back at the time when they had to select a commercially available product there weren't too many of those around.

Despite the temptation to "do it yourself" organizations should not oversight the long term implications of developing your own software and the rules of economics that will sooner or later come into play.

A home grown system typically serves a single organization, so by definition it is a monopoly in relates to its "target market". We all know very well what the word monopoly entails. Lack of incentive to innovate and inefficient organization structure are common characteristics.
The biggest challenge, however, is that unlike real monopoly, home grown system does not generate any money. The software industry is built on copy & paste, or in other words: develop once, sale many times. An independent software vendor will look on its existing or potential customers to sale and fund new developments. The bigger the development the hardest it is to find a single customer which will be willing to carry alone the development cost. This is however exactly what is expected from an organization that maintains a home grown system to do for every new development.

Looking back on those organizations I visited, all of them with no exceptions shut down their development shop and made the switch to one of the big EMR players. It seems that in the long run even those wealthy organizations could not escape the rules of economics.

Comments

Popular posts from this blog

FHIR Status Check

 More than 2 years have past since I wrote my article  on the Fast Healthcare Interoperability Resources (FHIR®) standard and it’s time to do a quick status check and revisit the predictions I made back then. The FHIR standard continues the strong trajectory of adoption and is now used across the globe. The application programming interface (i.e. the FHIR API) is available in most major EHR systems today. According to the US Office of the National Coordinator Health Information Technology an estimated 85% of hospitals have FHIR in their systems. The NHS has been quick to adopt FHIR and the adoption curve in the UK is high. The NPfIT (NHS Care Record Service) HL7 V3 interfaces are being redeveloped in FHIR®, and new NHS specifications such as the CareConnect standard for secured Transfer of Care  are being specified in FHIR® by default. Despite the industry enthusiasm about the potential of FHIR still the old and faithful HL7 v2 remains the predominant interoperability standard in use t

Hospital CXO - A new well deserve seat at the executive table

I once asked the CEO of a large hospital what will be the main KPI to measure how well the hospital is doing. The CEO immediate response was that the best indicator would be how satisfy the patients are. In a stressful and overloaded environment such as a hospital, it is easy to focus on the disease and forget about the patient. A chief experience officers (CXO), or other similar titled leaders, is a new member in a hospital C-suite. The role of a CXOs have gained scope and respect in the C-suite as studies show how experience affects all aspects of care. There is a growing body of evidence supporting that the association between better patient experience and health care quality. For example, a study found that a higher CMS star rating was associated with lower patient mortality and readmission's.  One of the drivers accelerating the adoption was the US government decision to start mandate measuring patient’s perception of their care and tied reimbursement to those scores. Beyond t