For decades, most of us working in health informatics and e-health have lived on the assumption that ‘interoperability’ is one of the main things we are trying to achieve, and that it is the most important because the lack of it blocks progress on nearly every other priority. In the last decade, the gold version of interoperability has become ‘semantic interoperability’, a fabled Nirvana in which today’s sewers of recalcitrant proprietary data are magically transformed into a sea of pure Evian whose meaningful molecules will be ‘understood’ by drooling next generation apps that will instantly discover what is wrong with each of us, and tell us how to fix it.
I have no doubt that exactly the same delusions afflict at least some other domains, perhaps less those that simply cannot afford systems not to talk the same language, such as mobile telephony and industrial control.
This Nirvana will never be reached by the current methods. Some would say it is an illusion and can never be reached by any method, but it is clear that they are wrong.
Four hundred years ago, if you wanted to travel in Europe (in an intelligent fashion at least), you needed to learn some basics in numerous languages. About a century ago, a modicum of French, German, English and any Slavic language would get you very far indeed, and today, you need just one language to order a latte, go to the theatre or buy a train ticket: English. But go and meet those in their 20s all around Europe, not to mention middle class India, and half of Africa – all those places where English is a second or third language – and you discover they can do far more than order a coffee; they have internalised English and can have a deep discussion about Game of Thrones season 4, or the senselessness of Brexit. There is now a common English all around the world, owned by nobody.
In the more rarefied atmosphere of serious science and philosophy, the single language had of course already been achieved many hundreds of years earlier – Latin. This was the language in which Henry VIII wrote Assertio Septem Sacramentorum (“Defence of the Seven Sacraments”) in 1521, the language in which Copernicus, Newton, Liebniz and every other learned European communicated, and in which Linnaeus named everything he saw in the natural world. In other contexts, French was another common tongue, at various times permitting one to use a single language in much of Africa, be understood by the polite society of St Petersburg, to discuss Asian art in the far east with educated Vietnamese and to conduct international diplomacy.
In each of these contexts, human communication, at least for a very large core set of concepts became its own thing, no longer owned by any culture, just as English is no longer owned by the Anglo countries today.
The problem isn’t that all IT systems and products in health can never in principle speak the same language, it is that trying to achieve this state of affairs by thousands of disconnected developers trying to make connectors based on ad hoc messages between those systems is a fundamentally flawed approach, at least in the long term. In the short term, of course it has utility, and there is no argument to say that lab result messages between a pathology laboratory and a GP clinic are not useful. However, even lab messages are different in many countries: different coding systems, structures and transactional semantics abound. Not one of the lab messages used today in Brazil would work in Germany, and Germany’s do not work in Norway.
According to the language metaphor, today’s health IT systems with their attempts at interoperability look as follows. They secretly know a lot but can hardly say anything to each other.
The whole mentality of ‘interoperability’ is that if we just do a better job on standards, we can get all those systems and products to talk to each other. But, other than for ordering a coffee or a train ticket, we can’t, unless those systems and products fundamentally change, and become clients of a common language, rather than obstacles to its achievement. In our domain, this needs to be a common health computing language.
This state of affairs can only be reached by separating out the basic components in those products that create and manage data – components that create the utterances of these systems – from those products and standardising them across the whole industry into common platform components. An analogy is the way TCP/IP is standard across the entire internet, and most private networks as well: no product or vendor owns TCP/IP, but they all speak it. And remember: TCP/IP was for a long time only a de facto standard, not a de jure one. (The de jure one, ISO’s OSI 7 layer standard made for pretty diagrams in my networking textbooks in the late 80s, and that’s where it stayed).
What does health data consist of? It consists of statements that can be recorded in the course of clinical care, planning, research and other activities, e.g. public health and reporting. These range from the mundane, such as vital signs observations to semantically rich artefacts such as care pathways, care process workflow definitions and clinical trial data-sets. Today, nearly all commercial EMR systems and clinical applications – including open source ones – have their own private version of all of this, with a few exceptions. According to the interoperability religion, the standards that the faithful work so hard to perfect in ISO, HL7, CEN, ASTM and other such places (I was one for many years) will provide the means for these thousands of products to talk to each other.
This is not without some truth; but following the European languages analogy, all we are really achieving is that those systems can order coffee or a train ticket from each other. They will never internalise a rich common language of healthcare, because each already has its own rich private language, and the mounting numbers of interoperability connectors are mostly mutually incoherent at the semantic level.
To reach a situation where all health IT products understand vital signs observations, care plans and clinical trial data-sets in the same way, they must give up their private languages (or reserve them for Christmas dinners with family and friends) and learn an English of healthcare computing. In other words, we need to forget the idea that they have their own data. Or more precisely, that they have their own language in which to create their data.
Instead, commercial products (including open source) need to work on the principle that they function as applications and intelligence, over a platform that manages their data, and thus, embodies the common language.
This is not a completely new idea of course: some people in the terminology domain have claimed that if we could only agree a single terminology, the battle would be won. This is not really true, but it’s not entirely false either. If terminology were to be unified and ‘completed’, it would be a like a dictionary plus minimal grammar book, in the language analogy. Terminology is already something not owned by health IT product vendors, so that’s a good start as well. But having a dictionary and grammar rules doesn’t mean you know how to say anything useful: you need a rich description of the aspects of the real world that you want to talk about. If you want to order a coffee, you need to know what ‘coffee’ is, and that it is something you can ‘order’. Terminology might be able to say that a coffee is-a beverage is-a food, but ‘ordering’ is a more sophisticated concept and terminologies quickly run out of steam. If you want to say ‘madame, I need to have a 3 day stop in Lisbon on the way from London to Rio’, you both need the same conceptual schema of air travel in Europe.
In philosophy, these descriptions of reality are ontologies, and today they may be realised as formal ontologies, but also in other ways: well designed software class models, business rules, domain content models (archetypes, CEMs, CIMI models in e-health) and ‘templates’ for many kinds of instantiable entity (e.g. data sets).
The vendors of some of today’s healthcare products would no doubt be offended or even outraged by these claims. But I doubt very much that any of them does not agree with them. The reason for that is that even the biggest, most expensive solutions (Hospital Information Systems, EMRs etc) cannot today hope to cover all the kinds of activity or data sources in the real world of clinical healthcare or research, even if the opposite was once the case. Today there are tens of thousands of e-health products and solutions, not just dozens, and the cacophony of non-communication is no longer sustainable or solvable by teaching each one to speak to others via some minimal standard messages.
Indeed, the inability to obtain data for a given patient from all (or even most) of the other products used during other encounters of the patient with the health system is now impeding the function of the incumbent large products. Some of the ‘big 6’ EMR vendors have already realised this, some continue to resist, perhaps due to lack of an attractive business model.
Getting from where we are, which is thousands of babel-ing products each talking past each other (succeeding only in ordering the odd coffee, probably delivered cold) and the prospect of interminable building of separate data pipes for each specific communication, to a situation akin to everyone having learned English – properly – would seem to require a revolution. And there will be a revolution, because every one of those products wants to exchange rich health data to do its business, but cannot, other than with a few tailored friendly systems, and on a narrow range of matters.
To change metaphors, it is if we have realised that there are 50 different railway track gauges, trains that can’t go anywhere except their own limited track, and an explosion of customers demanding to be able to travel across the whole country, without changing trains.
The main reason there will be a revolution is that there is now a vast unmet need for the new applications and devices we see appearing every day, not to mention new generations of analytics tools, to connect to a common stream of patient- or cohort-centric health data. Not solving the problem is blocking the future. Solving it the old way – an endless production of ad hoc messages, documents, or ‘profiled resources’ – will be a gargantuan effort that will exacerbate the already unsustainable healthcare spending in the OECD countries, particularly the US, and it will be ten times slower. But why would we do this, when a much better and more cost-effective future is available?
A second very strong driver for the separation of patient healthcare data from vendor products is the growing realisation that patient data must be a holistic entity owned by the patient, or a by a trusted third party on behalf of the patient, rather than being a collection of disjointed data heaps jealously guarded by separate companies.
The end-state situation we seek is a platform the implements the language, concepts and formalisms of healthcare, just as English does for modern society, TCP/IP does for the internet, and 4’8″ rail gauge does for train travel. This is what the future looks like:
This future corresponds to a major re-arrangement of the health IT vendor industry. Rather than each company having its own ‘modelling’ groups and data architecture, specialists will work in companies that make platform components, or else specify the platform. This will save billions, and wipe out most interoperability problems. The designers and developers who work on applications today will work in a new way: with a common language and model library built into a standard platform that they simply instantiate and use, rather than some private database model that looks nothing like anything anyone else has. The bigger companies might even start innovating again. A myriad of smaller companies that are currently paralysed by the prospect of building their own health databases, or else implementing endless ad hoc messages and documents just to order a coffee, will plug into the common platform at minimal cost, and be liberated to concentrate on their innovation.
A new category of work will become prevalent: development of domain models, by domain professionals. Some of this exists today, in the form of authoring of care pathways, terminologies, clinical archetypes and biomedical ontologies.
This separation of common semantics from competitive functionality will enable the health language formalisms and models to be developed properly and taught pedagogically, rather than being represented as the thousands of mutually incoherent data dumps we see inside today’s products.
Now, in the world of politics, I am not big on revolutions. They are usually destructive, promising everything and resulting in terror. We don’t want that in healthcare IT! Neither am I against corporations or commercial activity, at all. But I am for economic efficiency, innovation, and making sure business serves humanity, not the other way around. And the healthcare IT industry can do so much better for the patients and professionals it serves.
So I should be clear that I am using the word revolution mainly metaphorically; what I believe we will see is more like a phase change in the physics sense. Remember creating a supersaturated solution of alum in chemistry class? Slow, distinct nucleations, followed by rapid conversion of liquid to crystal. A beautiful sight.
wolandscat
Woland's cat 
What makes it so interesting to talk with humans from other countries, that we learn for that purpose a second or even third language, English as you say.
It is not for ordering coffee, or buying a train-ticket. We let our phone do the talking, there are smart apps which can translate standard messages without errors. While using them you learn, and next time in Rome you know how to order a coffee without the app.
When we want to talk with foreigners, we want to talk about art, television, about politics, about philosophy. We want to talk about things which are not simple facts but which need good explanation but also good listeners who understand the feelings and thoughts we want to share. That part is hard.
English is not my first language, not even my second. I spoke a local dialect, Dutch and German before I learned English. This is common for people from the region where I was raised. I think German people find better understanding of their language in the Netherlands than English people do. But German people can never assume that someone in the Netherlands speaks German, there might be some old sensitivities, but as soon as they start talking something that sounds from far a bit like Dutch or kind of English, the Dutch immediately start talking kind of German, sometimes even understandable. The German language is the most complex of the western languages, even many Germans have problems with it. German folks rarely speak English. French even less. In France, when you go to a GP, chances are that he/she does not speak English, or did not practise it for 20 years. They don’t practise it from tv, the Game of Thrones are dubbed. Maybe the French even dubbed Allô Allô, that would be really funny: “Une blague allemande est pas pour rire” ( “A German joke is no laughing matter” https://www.youtube.com/watch?v=g4ik9vUkj-Y )
Same in Spain (they regard their language as a world-language). And don’t mention the Belgium’s having three official languages in their small country. They have a language battle. French speakings are taking over villages, and they demand their language to become official language in a village where 30 years ago Dutch was the official language, which means that in school, French will be spoken. They hate each other, except when they do good at the FIFA World Cup. Even the police was not able to work together with departments in other language-areas.
How good would it be when a foreign GP had a SNOMED dictionary and you could explain in SNOMEDian what your problem is. Many conversations at the GP-office can be coded.
So, my point, language has a lot to do with history, with power, with culture, with economics and many other things. You still need a lot of languages when you travel through Europe, and you want to talk with people who have not been to university, recently.
You can love a language, or hate it, or find it easy or difficult.
How much different is this in science. People from all over the world work together to do inventions on every thinkable subject, everyone in its own language ordering the coffee, but communicating complex subjects without problem all around the world. Why should that be different for medical science?
I have been last half year a close witness of long taking healthcare-process. Every clinical step (it were hundreds) that was taken could be coded in SNOMED. So there are no cultural clashes, there are no lingual dominances, everything is facts.
Maybe a good example would be needed to be convincing. Could you please add that? Maybe I feel sorry because the example is so stupid simple, that I did not come to it. Then I will blame the heat.
Thanks.
Bert
You can only code universal truths using SNOMED – i.e. categorise an individual (e.g. a particular patient observation such as an ECG) as being an instance of a class (e.g. atrial fibrillation). But if you want to define the thousands of information structures relating to patient encounters, diagnosis and treatment generally, SNOMED won’t help. SNOMED has no idea what a 12 month diabetic review, or the data sets for ante-natal monitoring look like. These things are templates for information about individuals, not universal classes and differentiae, which is SNOMED’s business – or at least attempted by SNOMED (really it is the business of ontologies). SNOMED also doesn’t know much about drugs, Care pathways or guidelines, or process in general. There is no single source of the common health language: it is a semantic tool-box made of many things.
Thank you for the language and coffee metaphors to explain the 2 essential components of scientific philosophy – ontology for what exists (all the components of “a coffee”), and epistemology for the language to describe them – and applying this to the Health IT crisis.
On the terms used to describe the change required, “Revolution” is fine. If the term historically meant episodes of terror, it was redefined to “paradigm shifts” that are decades-long, by Kuhn’s 1962 classic “The Structure of Scientific Revolutions”. This shows how the incumbent paradigm fights long and dirty to protect its interests – and few domains are as expensively embedded in society as Health IT. Meanwhile the new paradigm is used, often in secret, by the craftsmen who get stuff to work – and we can do this freely, unlike the C16 astronomers using heliocentric theory to predict the heavenly motions, who risked a ghastly death if their methods were discovered.
So we are in a Scientific Revolution, and can predict failure of the “multiple crafted interconnector” paradigm due to non-scalable complexity, semantic confusion when spread across organisations, and the huge costs: as an endless revenue generator for eHealth suppliers, it’s an endless cost to the public purse that patients and societies won’t tolerate.
This Social Science view matters in bringing the issue beyond the tech bubble to wider public awareness. For instance, if current Health IT is described as “privatisation of our health data by stealth” to non-tech people, they get cross. To describe it like this is to challenge the publicly-accountable health providers to stop procuring those proprietary systems that “privatise” our data.
When patients realise that their data is not freely interoperable for their own care, they get even more cross, and if they’ve suffered harm they get angry.
So it is already political, and it’s now gone legal in US, where the 21st Century Cures Act of 2016 empowers patients to act on this. Its new offence of Information Blocking, managed by federal systems to collate the individual patients’ harms, is intended to drive suppliers to invest in current Open Platform technologies whenever it can be shown to work better than proprietary tech.
That some IT suppliers persist their lucrative proprietary systems, instead of re-engineering their systems to mesh together using the “lingua franca” of a common and free-to-use architecture, is not trivial, and you are calling it out. Do you think the concept of Information Blocking can help do this in nations that don’t yet have the legal levers, and could be an engine of this revolution?
That is actually a very good question. If we are looking for ways for consumers to force HIS vendors to change their behaviour, this is probably the kind of thing that could work. But it relies on a) real, enforceable legislation behind it and b) educating sufficient numbers of the public that they do in fact realise the problem and become active.
Yes to a) pending legislation we can learn from the US initiative.
It was cross-party and developed over many years, as the unsustainability of the current paradigm was long obvious. So it gives teeth to HIPAA – though we don’t even have a law to drive portability.
And to b): not sure that consumers can effect this beyond the PHR space. But collectively, the “social” level of our giant socio-technical enterprise needs active promotion to inform outside the tech bubble. Such a strategy might use your language and coffee metaphors to inform consumer organisations or politicians about “Progressive Health Informatics”
And C21 Cures Act does use the ONC and its http://www.healthit.gov/form/healthit-feedback-form to collate consumer feedback by category … do we do likewise?
I share your view, conceptually, that “platform” will disrupt the health IT industry and dissolve the “semantic interoperability” problem once for all, if by “platform”, you mean “platform business model”.
“Platform” is one of the frequently misused terms in business and in technology. A “platform” can refer to a piece of technology, such as an integrated suite of software products (i.e., “integration platform”). It can also refer to a business model.
Platform business models create value and build networks by facilitating exchanges between interdependent users and resources, and connecting consumers and producers. The fundamental difference between traditional product/service-based business model (aka linear business model) and platform business model lies in the “supply chain”. A linear business model owns the means of production and inventory via a supply chain. A platform business model doesn’t own the means of production, instead it owns the means of connection. (This is well explained in the book “Modern Monopolies” by Alex Moazed and Nicolas L. Johnson).
Google, Uber, Airbnb and Facebook are all platform businesses. Apple and Amazon have a hybrid of linear and platform business model. Most people mistake Netflix or HBO as platform businesses when in fact they are linear businesses. This is because they create or licenses their content and sells the content through subscription on their technology platforms.
Platform business models aren’t exactly “revolutionary”. Farmers’ markets and bazaars in ancient Mideast, today’s shopping malls are all platform businesses. A platform business creates value by turning connections into transactions. Therefore, defining core transaction and establishing rules and standards to govern the network are the essential requirements for designing the underlying platform. I think that your notion of “platform” is referring to the underlying platform.
How does platform business have anything to do with semantic interoperability? Since EHR systems are built to record, track and bill procedures rather than providing a coherent and holistic view of the patient and clinical decision support, a platform business model or a hybrid that connects patients, healthcare providers, payers, pharmacies, and public health officials and researcher would fulfil the needs. The Health Information Exchanges (HIEs) seem to offer hope but I am not sure about their business models. The disruption will most likely come from technology companies and it won’t be long (now that the U.S. has issued the final rules on interoperability and information blocking with the 21st Century Cures Act Final Rule).
If I misunderstood your notion of “platform”, it is because of my own cognitive bias and I apologize.
No misunderstanding here! Your view of platform is pretty close to mine; a bit more business-oriented. Your explanation is a summary of the ‘platform as a broker’ concept, i.e. connecting specific demand with supply based on specific information, such as AirBnB does by connecting holiday customers with owners of accommodation. In this sense, modern business ‘platforms’ are just using computers to do a job humans do or did, as you point out – professional collectors, trade agents, real estate agents, even match-makers (they still exist in the orthodox Jewish community among others) – they all use specific information provided by clients to find suppliers. The better ones do this with great accuracy and minimal time-wasting or near-misses. In real estate this translates to the rare experience of being shown houses by a real estate agent that really do correspond to what you were looking for.
The key to all this is very high-quality information, and high-quality connectivity / interoperability through the various parts of the broker network. So when I talk about the ‘platform’ I am mainly (as you point out) talking about the platform ‘system’ or ‘network’ – the entity that must be in place to achieve highly efficient information sharing, needs-brokerage and notification.
In e-health, the question of ownership of the platform is less clear than for an Amazon or AirBnB, because in e-health, no single entity (not even an Amazon, Apple or Microsoft) could provide the totality of the platform. For example, terminologies are provided by various international organisations (WHO, WONCA, Snomed Intl etc); semantic models are provided by different orgs – e.g. care pathways (NICE, NCI…), guidelines (professional colleges, university hospitals, …) domain information models (VA, Intermountain HC, openEHR, …); enterprise process models (jurisdictions, healthcare providers); payment rules and structures (various public and private entities); and that’s before we even get to the technology part.
So I think in e-health, any business model has to be a tacit technical cooperation process across entities, with platform ‘definer’ and ‘mandater’ roles being clear, as per this older post https://wolandscat.net/2014/05/07/what-is-an-open-platform/ , rather than a single organisation. And to make things work, the platform probably has to be run on a not-for-profit (i.e. necessary cost) basis, which is quite a departure from AirBnB or Amazon. I think that what is in common is the ‘system’ notion of the platform – what it is you have to put in place to actually achieve the connections.
Thank you for the clarification! Thomas. Your 2014 post, “What is an Open Platform?”, is one of the most comprehensive that I have read. Combined with this post and your more recent post, “Why using HIT standards fails to achieve interoperability”,
, together they would make an excellent white paper.
You break down of the platform ecosystem roles is thorough and well-articulated. However we may group them into three or four categories:
1. platform owner (for an health platform, this can be far more complicated as your point out)
2. platform provider
3. platform producers/suppliers, and
4. platform consumers/users.
The task of building an open healthcare services platform is monumental. However, Rome wasn’t built in a day. I am a believer in evolutionary design and architecture. Amazon, Facebook, Airbnb, Uber have all evolved significantly over the years but at the same time “seamlessly” to the end users because of the “familiarity principle” in design. The reason that healthcare providers rate VistA systems highly is because it is built over time and thus changes are gradual to the users. We need to do the same for healthcare services platform.
The million-dollar question is: where do we start? To me the answer lies in the concept of “minimal viable product” – the basic requirements for achieving the 80% with 20% of the effort, the Pareto principle. My humble observation from my limited experience with healthcare standards is that over specification has become a barrier for health IT to move forward.
From financial dimension, the drivers for building healthcare platform business will come from the demand for sustainability, composability, scalability, and agility to keep pace with the advancement of technology and medical research. Today’s investors value platform business models more than linear business models. That’s why I see the disruption coming from the private technology sector.
I do have one question for you: with HIEs sprawling across the U.S., why isn’t interoperability accelerated? Are HIEs platform businesses or linear businesses(do they have their own data stores and supplying their data from the different EHRs)? Thank you!
Never mind my question above. HIEs will certainly have a hybrid business model. There are similar organizations in the financial industry such as credit bureaus that create value and generate revenue from the raw financial data that they collect which give the credit bureau a unique insight into the credit risks of individuals and banks etc. which in turn benefit both individuals and banks. This is just one example of how credit bureaus create value for data providers and consumers. I suppose that the real challenge for healthcare services platform business is in the design of the platform.