What is a modular openEHR based electronic health record? How does it differ from a traditional model?
From monoliths to modules
The vendor and technology neutral openEHR data model is revolutionary in the health care IT market: the openEHR data model makes applications semantically interoperable. The future electronic health record will not necessarily be a vendor-specific monolith, where the user interface, business logic, data repository, data model and workflow are bundled in the same proprietary software. In the future it will be easier to split electronic health record functionalities to separate modules that can be provided by multiple vendors.
Modularity is enabled, since openEHR based electronic health record allows the user interface, business logic, data repository, data model and workflow to be separated from each other. Each functional module stores the patient data to a common openEHR data repository using standard APIs. The data are immediately available for another module – taking into account data privacy and security. This is how healthcare organizations can achieve flexibility to their procurement processes: it is possible to acquire the functionality that is necessary at the moment and from the vendor with the best-of-breed module. Instead of a broad monolith suite, electronic health records can be built from multiple functional modules.
A common user experience (UX) is often provided to get access to the functionalities of different modules. It feels as if you were using one system. The common role based UX could be created by the principal module vendor or by an external stakeholder. The integration of modules happens on the data level via the common data repository, but also on the process level (management of patient pathways) thus reducing the need for multiple complicated integrations or migration when the modules are to be changed. Electronic health records can be built in a managed and cost-effective way and the required changes are fast.
There is a concise comparison of the both approaches below.
Why the new approach?
Traditional systems are not able to meet changing user needs or easily adjust to new ways of working. Novel and more flexible approaches are needed. Patient centricity demands capabilities to build cross-organizational patient pathways. We need to be able to utilize data to its full extent across different systems and organizations; viewing data from different sources is not enough. There is a need for clinical decision support, analytics, automation etc. Population level analytics is also a hot topic today, but to enable analytics the data needs to be harmonized on the semantic level. There is also a desire to acquire different parts of the system from different vendors, since no vendor can be an expert in all areas.
What kind of benefits can be achieved with the new architecture and semantically coherent data model?
It is easier to utilize data from a separate data repository and through standard APIs. Any third party vendor can be granted access to the data using their own tools. Semantically coherent data can be used for analytics even in other applications based on the same open data model.
When modules are designed with the openEHR principles it is possible to add new modules when necessary or even replace a module with an equivalent one from another vendor. Electronic health record can be changed in a more controlled way without a cumbersome migration – resulting in remarkable time and cost savings. This approach also diminishes the risk for losing information. Furthermore development of smaller and specialized modules is faster and niche functionalities can be built.
New innovations as part of electronic health record
Deployment of new innovative electronic health record functionalities is more agile when a common data repository and common technical services of the platform can be used. This also creates opportunities for smaller system providers. Examples of such innovative functionalities could be a mental health module for young people, a dental surgery module, emergency care module for children or even a module for parents to follow the growth and development of their child. Functional electronic health record modules might be superior in analyzing the data or providing new and intelligent ways to utilize the data. End-users can also actively innovate and develop functionalities together with the industry.
New ecosystem thinking boosts creating and utilizing innovations: different vendors complement each other’s offerings. A new approach needs to be taken also in procurement offices, since it is unlikely that innovative niche vendors have been able to build several large references or have gained revenue that is typically required in procurement specifications. On the other hand the international openEHR data model gives small module vendors easier access to the international market and enables them to act as a part of an ecosystem.
Modelling and management of patient pathways
The latest openEHR specification work covers modelling and management of cross-organizational patient pathways. Complicated patient pathways or parts of them can be modelled and the execution of the pathway can be followed visually. The pathway itself can contain automation and decision support at the pathway crossroads. It can also utilize external decision support modules. The aim is to manage all social and health care pathways of a person with the same pathway module. It is also possible to follow the execution of the pathways in a summary view in real time. In a traditional electronic health record or social care system the management of pathways is restricted to a particular system only.
Old and new – hand in hand
openEHR based electronic health record projects typically start by building a regional or national openEHR data repository. Old legacy data are transferred to the repository on-demand when the patient seeks for care. Data migration can also be performed as a continuous process in the background. Once migrated the data are also harmonized to openEHR data model. All new data are stored to the repository using the openEHR data model.
Electronic health record functionalities are built step-by-step, module-by-module utilizing the data repository and common technical services. Legacy systems stay active until all core functionalities exist as modules and legacy is not needed any more. In reality there is co-existence for a lengthy time period. Naturally some IT systems will not change to openEHR and will communicate for instance with HL7 FHIR standard.
The writer is PhD Hanna Pohjonen, openEHR Ambassador Finland and a Healthcare management consultant from Rosaldo Oy. Hanna has been consulting in various regional and national eHealth projects altogether in 30 countries.
This article was originally published by openEHR.
