This article originally appeared as a column in “Transforming Healthcare Together - openEHR Supports Innovation”, a collection of contributions by partners of openEHR International.
One of the challenges concerning the storage of healthcare data, is that there are many different kinds of data and each comes with its own specific challenges. In this article we will zoom in on demographic data, such as name, age, place of residence, relations, etcetera.
The openEHR Reference Model has been capable of storing such data since the very beginning, but many parties have opted to use HL7 FHIR to store demographic data instead, or they do not standardise demographic data at all. Why is this the case and couldn’t we use openEHR instead? At CODE24, we have used the openEHR Demographic Model since we started – in this article we will share our perspective.
One of the issues many face when they consider using the openEHR Demographic Model, is that the demographic data is not stored under the EHR, but ‘next to it’, in a sense. This way, you can associate an EHR with a patient, while ensuring the security of the data. However, it also means that you cannot use the AQL to query demographic data, since that kind of data not supported by the AQL specification yet. Another issue is that demographic archetypes needs types and definitions from a different namespace, which makes it difficult to use that data while you model clinical archetypes.
For many years, the aforementioned lack of AQL support, the scarcity of available archetypes and the fact that there were no API specifications, meant that vendors did not see a need to invest in implementing the openEHR Demographic Model. There was no specific demand for it from healthcare organisations either – there were alternative solutions available, so it was not cost-effective to look at newer, more innovative solutions. This lack of demand will also have been a factor in the lack of interest on part of the vendors.
Thankfully, these days we do have specifications for openEHR Demographics APIs. There has also been a shift in the market, meaning there is a growing interest in what openEHR has to offer in terms of the storing and modelling of healthcare data - including demographics.
At CODE24, we have the benefit of having used the openEHR Demographic Model since the very beginning. We could start with a blank slate, using only the openEHR specifications. At other organisations, there are often existing (administrative) processes for which solutions for storing demographic data are already in use, such as HL7 FHIR. Think of, for example, invoicing, user management or permission and audit trailing. We had no such legacy and were free to fully embrace all facets of the openEHR Specifications - including the Demographic Model.
Over the years, we have been very happy with our choice to use the Demographic Model for the practitioner caseload, care teams, patient relationships, the admissions process, etcetera. It has proven to give us the flexibility we need and provides us with a solid foundation upon which to continue to build our portfolio of solutions. When you store more data according to the openEHR specifications, you can work from a single source to a larger extent and there is less need for mapping and copying data in order to share it. Also, openEHR is very well suited to store the history of patient demographics, due to the versioning mechanism available for all openEHR persisted data. With alternative setups, older demographic data is often lacking (such as an old address, or older care relations). Having this data available is valuable for both research and prevention.
We much preferred using a single open standard as much as we could, in order to reduce the complexity of the code and system of what we were creating. Combining openEHR and FHIR specifications is, of course, in many ways still a standard way of working in the industry, but we prefer to store data according to the openEHR Specifications as much as we can. It has been specifically created for this purpose and we believe in its benefits.
For the past three to four years, interest in the openEHR Demographic Model has grown. There have been many meetings where we were asked to show the benefits of using the openEHR Demographic Model and Sebastian, as a member of the openEHR International SEC, has advocated for adding support for them in both the APIs and the AQLs. This has led to a draft version of these specifications for the APIs and we believe that a proposal for the AQL will follow before the end of the year.
Considering where the market is now and what challenges the healthcare IT industry is facing, healthcare organisations are increasingly exploring what openEHR has to offer. Subsequently, we believe that once API and AQL support is available, vendor support for using the openEHR Demographic Model will grow and more and more vendors will implement it. As CODE24, we would welcome such a development and look forward to sharing our experience with the openEHR Demographic Model with the community as needed.