While technologies change rapidly, the way of creating healthcare applications remains the same, to the exclusive advantage of those who produce them.
The geocentric system was the prevailing astronomical theory for about two millennia before being replaced by the heliocentric system of Nicolaus Copernicus. But what does all this have to do with digital health? The reflection came spontaneously to me when I was thinking about the comparison between the “app-centric” and “data-centric” vision that I talked about in this post.
So far, applications have been and still are the center of digital healthcare. Everything revolves around them, including the data that is an integral part of them. Companies that develop software invest time and money to build applications that are technologically updated and have a high level of configurability at the level of processes, forms and data. The fact that these are inside the applications and are managed in the code or in the structure of the database determines a considerable complexity which has repercussions in a series of critical issues: difficulty in preserving the concept of “product” compared to the “custom solution”; the effort to maintain and evolve the product; the fragility of some mechanisms which, if modified for a need, can negatively impact customers.
The use of service or microservice architectures does not solve the problem even if it mitigates it somewhat. The problem lies precisely in the approach which, in an increasingly complex and digital healthcare system, is limited by its very nature.
Comparing myself with software vendors on this topic, I observe how difficult it is for them to change the paradigm, i.e. the point of view from which to design a digital health solution. The idea of ”separating” yourself from the data is a source of skepticism about the actual feasibility of such a thing and concern about the possible loss of control over a fundamental aspect for every application.
Services or micro services are only good if they operate with their own database, something I fully control. Logically and physically separating data from applications is an understandable but difficult concept to accept.
Upon closer inspection, however, the resistance that exists does not only concern the technical aspects but is also of a commercial nature. Keeping everything together, with proprietary logic, ensures a strong lock-in on the part of the supplier which is not affected either by the transfer of the user license, nor even by that of the source codes.
Here then – here you will understand what Ulysses has to do with it – that placing a system in a customer ensures a lot of work in a captive market for years to come. An initial financial sacrifice, in the tender response, allows not only to recover the lost revenue over time but to defend one’s position with the customer for many years. If the healthcare company then wants to change supplier, the costs and difficulties of the migration will be borne by it.
But the transition from an “app-centric” to a “data-centric” vision is not the only aspect to consider. Some reflections must also be made on how the applications are developed. We’ll talk about this in the next post.
I like:
I like Loading…