In our earlier articles in the series "The Future of Data Availability in Healthcare," we highlighted the opportunities that open (healthcare data) platforms have to offer for data availability. But what does this mean for the architecture of healthcare information systems such as EHRs? What changes are required to deploy open platforms in such a way that healthcare can be truly data-driven in the future?
Separating the data layer from the functionality
In our article "Open platforms for optimal data availability in healthcare," we touched on it briefly: when we deploy open platforms for data availability, these open platforms contain the data and can communicate with the applications of all kinds of healthcare systems through open APIs.
This means, simply put, that health information systems themselves no longer contain data. The various health information systems access and process the data stored in a standardised way in the open platforms (more on these standards below).
However, this is not how most healthcare information systems are now structured - these now mostly do their own data storage based on a proprietary data model and this is technically intertwined with the rest of the application. So this needs to be separated so that the application can also be linked to an external data layer: the open platform.
A transition
This separation of the data layer and the application obviously requires something of the vendors of health information systems. They must (want to) facilitate this, so that we do not get stuck in the eternal duplicating data for the purpose of data exchange and really see a future in which data availability is the norm.
We see roughly three phases in this transition, which we present for the sake of example as the fictional scenario for Medical Center NL, which has an EHR in use:
Phase 1 - the starting point
Medical Center NL uses an EHR that has its own data repository. The rest of the 'landscape' of healthcare information systems is basically separate from this. When integrations are realised between the EHR and the other healthcare information systems (which actually make up the EHR landscape), data can be exchanged between the various systems, but this is effectively data duplication. This is currently the reality for many healthcare organizations/providers.
Phase 2 - in transition
Medical Center NL uses an EHR application, which is linked to an open platform that contains the data and various services - within the open platform, the Medical Center also has its own data repository. Other healthcare information systems can also interface with this open platform. This makes integrations easier and more accessible, and eliminates the need to duplicate data to make it available. Multiple systems can access data from the same source: the open platform. Other healthcare organizations can use the same approach and, when proper authentication is obtained, access the same data. At some vendors, such as CODE24, the data layer is already separate from the EHR, so this scenario is already a reality.
Phase 3 - the final scenario
The Medical Center puts together its own modular EHR . All these EHR modules together form the EHR landscape and this entire landscape accesses data from the same source: the open platform. Depending on which services are required at the data level, Medical Center NL can choose to work with one or more open platforms.
The federated layer
In the scenarios above, we have talked about "one" open platform for convenience - but in practice there will be several, each of which may offer its own services. We mentioned earlier in this blog series the importance of a federated collaboration layer to ensure that the data from these open platforms can still be aggregated to form necessary "big picture" data that healthcare organizations can access. What this federation will look like in practice has been defined in a sand-box environment by Ernst and Young (EY) and is available for open platform vendors to implement.
Open standards
The scenarios outlined above require standardization of storage and modeling of healthcare data. These are an sich not new concepts, the ISO 18308 standard for EHR architecture (on which, for example, openEHR is based) already stated:
"The EHR should [...] provid[e] a framework for standardized representation of information, and the consistent use of coding systems within that representation, that improves data quality at source and enhances reuse of data."
By standardizing data storage (and the structure of data models), healthcare data becomes multiple usable and interpretable across different healthcare domains and language areas. "Unambiguous healthcare information for primary and secondary (multiple) use" is one of the pillars of the European Health Data Space, see also this publication by Nictiz. High time for the government to give guidance on the basis of this ISO standard and to really start complying with it as suppliers.
Parties such as Nictiz and EY are conducting extensive research into the optimal coherence of standards for the Dutch healthcare system - see for example the "Research future scenarios zibs". The general consensus seems clear: we should look at a combination of standards, with each standard doing what it does best. HL7 FHIR will then be used for the secure exchange of healthcare data between systems, openEHR for the standardized storage of healthcare data and zibs, for example, as a link between data storage and data exchange.
If vendors want to support these standards and their associated "building blocks," they will have to look at the architecture underlying their applications. One possible solution direction, for example, is a more modular built system.
Challenges
This restructuring of existing architectures and applications will be quite challenging - this process is often complex and expensive. However, the need is becoming increasingly clear - data exchange alone is not enough. It will probably help if the government directs the standardization of data storage. In 2022, VWS has already chosen HL7 FHIR as an exchange standard in the field of data exchange - perhaps a similar choice can be made for openEHR as a standard for storing and modeling healthcare data (or at least a more active emphasis on compliance with ISO 18308).
The advantage of openEHR is, of course, that you don't have to completely reinvent the wheel yourself. Moreover, there is an active international community working on the further development of the standard (the archetypes and templates, as open source available within the openEHR Clinical Knowledge Manager).
From CODE24, we see the future in healthcare information systems as described above in "phase 3," but we are also realistic: with the wide variety of stakeholders, technologies and interests, it will take some time to get there.
Step by step
Despite the challenges outlined, it is important to lay the foundation for the healthcare information system architecture of the future as well as to keep each other on their toes. For example, we see that in recent discussions, the term "data availability" is sometimes already subject to devaluation subject to devaluation. Projects and POCs are started in the context of data availability in which the focus is on being able to read (a limited part of) data, using for example an FHIR Viewer, but in which the need to also be able to write directly at the source is not taken into account. A limited form of data availability in our opinion. In practice, therefore, people sometimes speak of "data accessibility" or "data accessibility," which are more accurate terms.
We must continue to strive for true data availability, largely eliminating the need to make data copies. To achieve this, adapting the architectures of our healthcare information systems is a requirement. It will require good cooperation between the healthcare organisations, the government, advisory bodies and suppliers to shape this architecture, without compromising on the end goal.
This article is part of the blog series "The Future of Data Availability in Healthcare," in which we discuss the possibilities of open platforms for data availability, the challenges of that solution direction, and CODE24's vision on this topic.
Also read:
