This text was triggered by discussions on Twitter in the wake of a Norwegian blog post I published about health platforms.
I stated that we need neither Epic, nor OpenEHR, nor any other platform to solve our healthcare needs in the Norwegian public sector. Epic people have not responded, but the OpenEHR crowd have been actively contesting my statements ever since. And many of them don’t read Norwegian, so I’m writing this to them and any other English speakers out there who might be interested. I will try to explain what I believe would be a better approach to solve our needs within the Norwegian public healthcare system.
The Norwegian health department is planning several gigantic software platform projects to solve our health IT problems. And while I know very little about the healthcare domain, I do know a bit about software. I know for instance that the larger the IT project, the larger the chances are that it will fail. This is not an opinion, this has been demonstrated repeatedly. To increase chances of success, one should break projects into smaller bits, each defined by specific user needs. Then one solves one problem at a time.
I have been told that this cannot be done with healthcare, because it is so interconnected and complex. I’d say it’s the other way around. It’s precisely because it is so complex, that we need to break it into smaller pieces. That’s how one solves complex problems.
Health IT professionals keep telling me that my knowledge of software from other domains is simply not transferrable, as health IT is not like other forms of IT. Well, let’s just pretend it is comparable to other forms of IT for a bit. Let’s pretend we could use the best tools and lessons learned from the rest of the software world within healthcare. How could that work?
The fundamental problem with healthcare seems to be, that we want all our data to be accessible to us in a format that matches whatever “health context” we happen to be in at any point in time. I want my blood test results to be available to me personally, and any doctor, nurse or specialist who needs it. Yet what the clinicians need to see from my test results and what I personally get to see will most likely differ a lot. We have different contexts, yet the view will need to be based on much of the same data. How does one store common data in a way that enables its use in multiple specific contexts like this? The fact that so many applications will need access to the same data points is possibly the largest driver towards this idea that we need A PLATFORM where all this data is hosted together. In OpenEHR there is a separation between a semantic modelling layer, and a content-agnostic persistence layer. So all datapoints can be stored in the same database/s – in the same tables/collections within those databases even. The user can then query these databases and get any kind of data structures out, based on the OpenEHR archetype definitions defined in the layer on top. So, they provide one platform with all health data stored together in one place – yet the user can access data in the format that they need given their context. I can see the appeal of this. This solves the problem.
However, there are many reasons to not want a common platform. I have mentioned one already – size itself is problematic. A platform encompassing “healthcare” will be enormous. Healthcare contains everything from nurses in the dementia ward, to cancer patients, to women giving birth, orthopaedic surgeons, and family of children with special needs… the list goes on endlessly. If we succeed building a platform encompassing all of this, and the plattform needs an update – can we go ahead with the update? We’d need to re-test the entire portfolio before daring to do any changes. What happens if there is a problem with the platform (maybe after an upgrade.) Then everything goes down. The more things are connected, the more risky it is to make changes. And in an ever changing world, both within healthcare and IT, we need to be able to make changes safely. There can be no improvement without change. Large platforms quickly become outdated and hated.
In the OpenEHR case – the fact that the persistence has no semantic structure will necessarily introduce added complexity in how to optimise for context specific queries. Looking through the database for debugging purposes will be very challenging, as everything is stored in generic constructs like “data” and “event” etc. Writing queries for data is so complex, that one recommends not doing it by hand – but rather creating the queries with a dedicated query creator UI. Here is an example of a query for blood pressure for instance:
EHR [ehr_id/value=$ehrUid] CONTAINS COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v1]
CONTAINS OBSERVATION obs [openEHR-EHR-OBSERVATION.blood_pressure.v1]
obs/$systolic_bp>= 140 OR obs/$diastolic_bp>=90
This is needless to say a very big turn-off for any experienced programmer.
The good news though, is that I don’t think we need a platform at all. We don’t need to store everything together. We don’t need services to provide our data in all sorts of context-dependent formatting. We can both split health up into smaller bits, and simultaneously have access to every data point in any kind of contextual structure we want. We can have it all. Without the plattform.
Let me explain my thoughts.
Health data has the advantage of naturally lending itself to being represented as immutable data. A blood test will be taken at a particular point in time. Its details will never change after that. Same with the test results. They do not change. One might take a new blood test of the same type, but this is another event entirely with its own attributes attached. Immutable data can be shared easily and safely between applications.
Let’s say we start with blood tests. What if we create a public registry for blood test results. Whenever someone takes a blood test, the results need to be sent to this repository. From there, any application with access, can query for the results, or they can subscribe to test results of a given type. Some might subscribe to data for a given patient, others for tests of a certain type. Any app that is interested in blood test results can receive a continuous stream of relevant events. Upon receipt of an event, they can then apply any context specific rules to it, and store it in whatever format is relevant for the given application. Every app can have its own context specific data store.
Repeat for all other types of health data.
The beauty of an approach like this, is that it enables endless functionality, and can solve enormously complex problems, without anyone needing to deal with the “total complexity”.
The blood test registry will still have plenty of complexity in it. There are many types of blood tests, many attributes that need to be handled properly, but it is still a relatively well defined concrete solution. It has only one responsibility, namely to be the “owner” of blood test results and provide that data safely to interested parties.
Each application in turn, only needs concern itself with its own context. It can subscribe to data from any registry it needs access to, and then store it in exactly the format it needs to be maximally effective for whatever usecase it is there to support. The data model in use for nurses in the dementia ward does not need to be linked in any way to the data model in use for brain-surgeons. The data stores for each application will only contain the data that application needs. Which in itself contributes to increased performance as the stores themselves are much smaller. In addition they will be much easier to work with, debug and performance tune, since it is completely dedicated for a specific purpose.
Someone asked me how I would solve an application for
“Cancer histopathology reporting, where every single cancer needs its own information model? and where imaging needs a different information model for each cancer and for each kind of image (CT, MRI, X-ray) +where genomics is going to explode that further”
Well I have no idea what kind of data is involved here. I know very little about cancer treatment. But from the description given, I would say one would create information models for each cancer, and for each type of image and so on. The application would get whatever cancer-data is needed from the appropriate registries, and then transform the data into the appropriate structures for this context and visualise the data in a useful way to the clinician.
We don’t need to optimize for storage space anymore, storage is plentiful and cheap, so the fact that the same information is stored in many places in different formats is not a problem. As long as we, in our applications can safely know that “we have all the necessary data available to us at this point in time”, we’re fine. Having common registries for the various types of data solves this. But these registries don’t need to be connected to each-other. They can be developed and maintained separately.
Healthcare is an enormous field, with enormous complexity. But this does not mean we need enormous and complex solutions. Quite the contrary. We can create complex solutions, without ever having to deal with the total complexity.
The most important thing to optimise for when building software, is the user experience. The reason we’re making the software is to help people do their job, or help them achieve some goal. Software is never an end in itself. In healthcare, there are no jobs that involve dealing with the entirety of “healthcare”. So we don’t need to create systems or platforms that do either. Nobody needs them.
Another problem in healthcare, is that one has gotten used to the idea that software development takes for ever. If you need an update to your application, you’ll have to wait for years, maybe decades to see it implemented. Platforms like OpenEHR deal with this by letting the users configure the platform continually. As the semantic information is decoupled from the underlying code and storage, users can reconfigure the platform without needing to get developers involved. While I can see the appeal of this too, I think it’s better to solve the underlying problem. Software should not take years to update. With DevOps now becoming more and more mainstream, I see no reason we can’t use this approach for health software as well. We need dedicated cross functional teams of developers, UXers, designers and clinicians working together on solutions for specific user groups. They need to write well tested (automatically tested) code that can be pushed to production continuously with changes and updates based on real feedback from the users on what they need to get their jobs done. This is possible. It is becoming more and more mainstream, and we are now getting more and more hard data that this approach not only gives better user experiences, but it also reduces bugs, and increases productivity.
The Norwegian public sector is planning on spending > 11 billion NOK on new health platform software in the next decade. We can save billions AND increase our chances of success dramatically by changing our focus – away from platforms, and on to concrete user needs and just making our health data accessible in safe ways. We can do this one step at a time. We don’t need a platform.