FHIR & openEHR, two standards – one mission
In the rapidly developing field of electronic healthcare, the interoperable transfer of health data, its aggregation into actionable information and ultimately the smart use of such information for the benefit of patients are crucial steps that must be considered when building a long-term sustainable IT platform.
With increasing connectivity in the internet age, information scientists have focused on core questions that – in a more general context – resemble the basic logistics of a retail business: How do I get my items quickly and safely from the manufacturer to my stores? How do I implement warehousing to support my businesses?
To an IT layman, it seems obvious that containers, pallets and boxes provide good order and protection for shipping, while your customers may ultimately appreciate when items are attractively presented, labelled and easily accessible in fixed and logical positions in your store. Take this image as a background for HL7/FHIR and openEHR working groups when they independently began (in the early 2000-2010s) to drive their respective developments in clinical IT towards standards with a focus on data transfer (FHIR) and data warehousing (openEHR).
What do shipment and warehousing scenarios – and equally FHIR and openEHR – have in common? Both employ internal structuring, a physical representation and control mechanisms to ensure completeness and proper loading of items. In the IT world, the structure equals to a so-called data model and their description in a formal machine-readable protocol language, the physical representation is represented by the storage type used and eventually the control mechanisms refer to data validation of detailed properties of the data itself against (equally detailed) constraints of the data model.
The FHIR data model provides the fundamental prerequisites and easy extensibility to cover virtually all aspects of clinical information, thus ensuring the secure transmission of clinical data. It offers adequate validation to guarantee the correct loading of data elements. FHIR information is stored and transmitted as independent electronic resource documents, with each resource representing a specific (clinical) aspect of the information. FHIR is ideally suited for implementing the networking of clinical data nodes with low development costs.
On the other hand, openEHR offers a highly detailed and rigorous data model based on the completeness and stability of reusable archetypes. These archetypes are carefully vetted and aim to represent the reality of clinical information as comprehensively as possible, including very detailed rules for data validation. By definition, the openEHR data model implements a patient-centric electronic health record (EHR). Information is natively stored in openEHR as tables of a true relational database. It provides additional support for data exchange via electronic document messages.
The crucial step occurs when the collected data is to be analyzed or used in other ways, for example, for training AI systems. For this, you need: 1) abundant, diverse and consistently error-free data. 2) the ability to extract precisely the cross-section of data required for your analysis from your entire data store.
Data consistency in large datasets is closely linked to rigorous and detailed data validation mechanisms, which in turn depend on the quality of the data model. Extracting relevant data for analysis requires the technical capability to perform group or join operations (similar to pivots or lookups in Excel) on data distributed across multiple resources or tables. This technical functionality is inherent to relational databases and optimized for performance, but more difficult to implement in document-based databases (accessed via indexing systems).
Based on the presentation in the preceding sections, it becomes clear that FHIR and openEHR are ideally suited to their respective strengths, notably data transport and data storage, and should therefore be carefully coordinated to fulfill their respective missions – and to ultimately to support the common goal of interoperable health data logistics.
Finally, let’s relax and get back to the retail world: How to handle eggs for cooking?
They are shipped on pallets holding egg cartons. In your private household you probably won’t pay much attention to the dimensions of the box, the egg size classification or individual batch and expiry codes. You’ll simply take what seems a to be a good value with an acceptable best-before date stamped on the box. However, if you are an industrial user of eggs, you should very much care about the packaging and parameters of your raw material. The packaging is tightly linked to your automated processing line, and the egg quality parameters to the overall quality of your end product. Any unexpected (and non-traceable) deviations may quickly escalate into an unrecoverable threat to your business!
To get the most value and safety from your data for your patients and other clinical stakeholders within your organization, ensure your data pipeline is sound – with the right tools and experienced partners.