Health IT: which problem are we trying to solve?

Recently I've seen many discussions on Twitter and LinkedIn about many topics on health IT like open platforms and vendor neutrality, monolithic vs. distributed architectures, silos vs. shared data, data first vs. API first, knowledge oriented systems, tools, standards, specifications, etc.

Some people just have questions and are searching for answers, other people just want to promote their tool or way of doing things, and other people, me included, want to understand which problem are we trying to solve, and make sense of the whole picture while removing the noise.

Sometimes these discussions are very productive and have are high level and deep into the matter, other times they are just religious battles like Linux vs. Windows or Open Source vs. Closed Source. So, lets try to make things clear, focus on the key points, and remove all the smoke and noise out there.

First we need to understand the current situation of a great percentage of clinical practices, hospitals, regions and national health care systems. We know the big players on each market, want to dominate, they want to sell their systems and promote/provoke a vendor lock-in, so they can send big bills out. That is how big companies work, the first thing is to survive and thrive, second is serving they clients, though there are exceptions, and there are internal goals not mentioned externally.

You know you have a vendor lock-in when the costs or disruption of upgrading a piece of technology outweigh the benefits. So you totally depend on them, and if some new requirement comes up, they will make you pay for it big time. This includes: new data requirements, which are very common in health IT, and new integrations, another very common thing.

In general the mechanisms these companies have to provoke a vendor lock-in are:

1. Custom/closed data model

2. Difficult/complex data export processes

3. Data fragmentation and data silos

4. Solution formed by many pieces of software integrated point to point and based on custom APIs/interfaces, communication protocols and messages

5. Forever increasing technical debt

6. Maintenance is don in an ad-hoc way, there is no common methodology

7. The time span of software is huge, at some point the whole platform looks like legacy

These are only some examples, and are focused on the technical part, there are also strategic, political and contractual areas that could affect vendor lock-in, but those are not my area of expertise, so others could talk about that.

On the other hand we have advocates of open platforms, open standards, open data models, etc. They promote those approaches to be able to tackle some of the mechanisms big companies use for vendor lock-in. The goal is to have a solution that is vendor-neutral and anti vendor lock-in. What they don't say is what is the cost of such approach. For instance, if we want to buy a solution we can go to one of those big companies, get a quote, and if we have the money, we pay that and we know we will have the system running, but with the "open" approaches we know nothing about that, though it "feels" to be a better approach in the long term, but in the short term the "canned" solution feels more practical.

So we know we need long-term solutions but can we wait 2, 5, 10 or more years to create our "open platform" or should we thing in the short term period? What would happen if we buy a short term solution and in the meantime we build the open platform solution? Is that even possible? As you can notice, I have more questions than answers.

If we consider the context, a clinical practices, hospital or even a network of hospitals can't wait 5 years to be able to create, share and analyze data, because they depend on that data for daily operations. But regional or national solutions might take 5-10 years to plan, design, develop and deploy.

So we are not trying to solve an interoperability problem, or an accessibility problem, or a technical problem, we are trying to mitigate the issues created by the strategies of some companies to keep them in business for a long time, making things more difficult to all the rest (patients, clinicians, managers, etc.)

My take would be little different, trying to consider all needs and contexts. First, if we don't have a common understanding of the data our platform will manage (at any level from local practice to national), we can't build anything. So, common understanding of data is a core requirement.

A generalization of such requirement would be: we need a standardized way of defining knowledge items that allow sharing and using them in a computable way. A "knowledge item" could be:

1. data structures

2. terminology, subset, mappings

3. calculations and formulas

4. rules and conditions

5. events

6. processes

7. services

8. ...

A "computable" way is to define a knowledge item in a declarative way that can be written down in plain ASCII so they can live in the form of files that have an internal format or syntax that a computer program can read, interpret and operate.

A "standardized" way is that the same constructs are used for the same "kind" of knowledge item. That is to have specifications on those constructs that express a full knowledge item.

If we can have the specifications of the standards used to express knowledge items, authoring tools to create and manage them, and repositories (Knowledge Base) to store and share them, then we will have a common knowledge layer as a base for our platform.

The experienced eye might noted that some of those knowledge items I mentioned above are interdependent, but some might depend on others without others depending on them, for instance you can't have processes without data structures, since clinical processes have steps for data input and data output which depend on the data structures. Similar for the formulas and calculations, those depend on variables and the variables come from data structures, without previously defined data structures we won't have any variables to use in formulas. Another case is rules and conditions, those also need variables that come from the data structures, but those could also get results from formulas and calculations as variables, then a condition is evaluated over those variables using certain mathematical operators. Data structures make use of terminologies, because the coded contents in the data come from predefined terminologies. And so on...

So it seems reasonable, but why don't we have such platform already built as a solution? First thing is: if different vendors would implement and share such platform, then their software becomes a commodity. Note the real value is in the knowledge, not in the software! The problem is not that the knowledge is not defined, is that these canned solutions have the knowledge hardcoded in their software in a custom way and is impossible to extract and share between different vendors or stakeholders.

In reality we buy huge software solutions that are very expensive to maintain and that prevent organizations from innovating based on the data they already have. So for years we try to adapt the monolith to our changing needs, which leads to ever increasing costs and technical debt, so we keep dealing with legacy for years instead of solving higher level problems for our patients.

One way of stopping this vicious circle is to focus on the knowledge items and try to bring in ways of defining, maintaining, sharing and educating about those items, while slowly creating a knowledge base (KB) from bottom-up. Then with a KB of certain size you will find there items to tackle new problems in a common standardized way, and when more and more items are used from there, the less you depend on a specific vendor and the more you can do with your current data.

During that process, you will find all new requirements could be satisfied by the new knowledge based platform, and at that point you no longer depend on the old vendor. So everything that has to do with the vendor is considered legacy. You have two options with that: 1. let it live there in the old platform forever and make the old platform read-only, or 2. import legacy into the new platform based on common knowledge items. Of course importing from legacy won't be something your vendor wants since it means the end of business for them if they don't transform they strategy into a open platform one.

Going back to the issue of not knowing the costs of implementing this new approach. since it's something new, at some point you need to take a little faith, or a better approach would be to have small and controller pilots to test the waters before going deep. A nice thing is in the last years more vendors are coming out focusing on this approach, and there are more projects wanting to invest in this approach. In some cases the clients don't even know they are following this approach, because the vendors have tuned their solutions to use this approach internally, so the external solution looks like any other solution in the market, but the implications of choosing one vs. the other are deep, specially in the long term.

My position is: the open platform approach is interesting, but applies better for networks of hospitals to national projects, not for lower levels in the short term. I think focusing on defining and managing knowledge items is the key, since it provides a high level library of items anyone can use for primary (health care) or secondary uses (research, education, epidemiology, etc.) but not all items have an open standard that expresses them in a flexible way, some might exist but don't have accessible authoring tools, or maybe there are no standard repositories for those items. So the market needs to mature in terms of 1. open specifications for knowledge items, 2. tools (open source or not), 3. accessible repositories / libraries of knowledge items that you can search and download items, or even contribute with new items or maintaining current ones.

A note about openEHR: that is one example of a good ecosystem for data structures, since openEHR has a set of specifications for a reference model, and a content model which allows to define our own data structures on top of the reference model, then it has a standardized methodology and tools for authoring and maintaining those definitions, and there is an international repository that people can use to search, download and use, and contribute those knowledge items. If something similar could exist for the other knowledge items I mentioned above (some might exist, specially in the terminology side), then this whole approach won't sound like science fiction.