My name is Severin Kohler. I’m a medical informatician and I began my journey as a research associate in Heidelberg, where I worked at the University Hospital and the German Cancer Research Center. Subsequently, I pursued a PhD at the Berlin Institute of Health (BIH) at Charité. Throughout my career, I’ve delved into various medical informatics standards such as DICOM, IHE, FHIR, and openEHR, always striving to broaden my expertise.
I first encountered openEHR when my former employer, the German Cancer Research Institute, joined the HiGHmed consortium, which is part of the German Medical Informatics Initiative (MI-I). This consortium aims to improve the accessibility of data from routine care for research. While my initial work was based on IHE, I shifted towards FHIR and openEHR later on. This is when I started to realize that only openEHR provides a comprehensive solution to the problems we face. Standardizing only the messaging – and by that the interfaces – always felt like treating the symptom, rather than the problem. For clinical data, the “less is more” approach isn’t doing the trick; in the worst case scenario, it’s endangering patients. Instead, we need to reach for the stars.
The Clinical Information Models (CIMs) we adopt are at best on a national scale. However, research projects are often done internationally. So different CIMs (or no CIMs) are to be expected. Collaborators need to agree on a way to work, and an elegant standard which solves this problem is the OMOP Common Data Model (CDM). This pragmatic CDM specifies fixed database tables that cover most of the typical data fields required for research today. Furthermore, it specifies vocabulary that harmonizes terminologies. Both features are real treasures. The fixed data tables enforce a common ground without the need of modeling, and the vocabularies ease analytics. That means that for projects with multiple stakeholders, everyone involved can integrate the required data into the CDM, which facilitates calculations without the need for clinical data exchange, since it’s the same model. OHDSI, the maintainer community, also provides different open-source tools.
One of the things we can do to integrate data into the OMOP is to build ETLs from the source systems into the CDM database. Often, this data has no standardized representation as a CIM, so we create a temporary data dump, and then abandon the ETL. On top of that, these projects often come with their own i2b2, CDM or proprietary solution. The ETLs that are created are not always reusable, which can result in a competition for repositories, further adding to the mess we have already created. Instead of shutting Pandora’s box, we leave it wide open.
To drive openEHR, we must be able to transform the data we laboriously integrated into the platform – using our highly semantically-rich archetypes – into other standards. It’s always easier to convert semantically-rich models into less semantically-rich ones. A comprehensive EHR approach should not only represent all relevant data, but also in the corresponding formats. The best way to achieve this is to attach mappings that are machine and human-readable to the archetypes and templates we create as part of our modeling effort, thus generating an archetypes polyglot and therefore the EHR-records themselves. There are currently two new open-source declarative mapping languages provided to the community. The OMOP Conversion Language (OMOCL) created by me and Diego Bosca for openEHR-to-CDM (10.1016/j.jbi.2023.104437), and the FHIRconnect language from Better.
As in the case of OMOP mappings, international archetypes make these mappings internationally valid. We hope that, in the future, there will be a community effort to extend the existing mappings to cover all archetypes, which will provide a built-in integration into the OMOP CDM for the international archetypes of each platform. Therefore, integration into openEHR also means having this data provided in OMOP (and this could be done for other standards too).
openEHR can achieve this – thanks to its international models and the fact that we subtract fields in templates instead of adding new ones – bringing us one step closer to a polyglot EHR.
Leave a Reply