📅 01 July, 2020•
⏱️2 min read
In writing up the technical review of openEHR, I found it difficult summarising what it did in as few words as possible. It's very easy to start talking about archetypes and templates, but then you need to elaborate upon these. By the time you get to the reference model you can lose an audience of clinicians. They don’t usually care how it works, only what it does and if it is any good.
OpenEHR is a specification, first and foremost. The core technology was developed to support longitudinal electronic health records and openEHR components are used to provide semantic understanding of the data that is incomparable to other solutions. It achieves this with tooling that facilitates the modelling of data into “archetypes” and “templates” to reflect specific clinical use cases. For example, recording blood pressure (i.e. the archetype) within a cardiovascular assessment (i.e. the template).
openEHR splits the definition of the clinical models from the governing data structures that define how they are to be used. This separation of concerns allows a clinical model to be independent from the underlying engineering that supports the wider system. Therefore, new models can be developed as required without necessitating development of the database and supporting services.
OK. Blank looks from a room of clinicians... Certainly, a one slide fits all approach was a little out of reach until I found a diagram in a paper by Sam Heard. Full disclosure: I cannot find it but will update this when it surfaces...
So with that in mind, I adapted the said diagram to the following:
Put simply, openEHR is a specification comprising of;