...
Usually such layers are built from at least two internal layers of software: the first being the abstract interface, the second being a set of bindings, one for each target database. In practice, there may be three layers since there may be an internal division between the logic for object and relational (and other) storage mechanisms.
Is persistence different in openEHR?
The openEHR architecture is different from other architectures in the health domain, and in most domains. The main difference is that it doesn't only have an object model from which to create software, database schemas etc, it also has also a layer of domain models called archetype FAQs. As a consequence, the part of the architecture that is defined as object models (known as the "reference model" or RM) is smaller and more generic than many models. The RM can be considered for most purposes as a typical object model. To get a feel for the architecture, the Architecture Overview (PDF) is a good place to start.
On one level therefore, persisting openEHR data is no different from persisting data in any object model of an equivalent number of classes (around 100, including all data types, EHR types, demographic types). There are two main challenges:
- bridging the object/relational gap: how to persist object data in relational databases which may be a requirement of the deployment environment
- the query trade-off: in any database, storing and retrieving numerous fine-grained objects is costly in terms of disc access time, yet the finer the granularity of storage, the more likely it is that the database's inbuilt query engine can query the data directly rather than forcing the application to retrieve and process the query itself..
These problems are related in their solution since if we opt for very coarse-grained data storage, the object/relational gap diminishes as well.
How can openEHR data be characterised?
Structure
To understand how to persist openEHR objects, we need to have a feel for the data. The business objects are known as "top-level structures" in openEHR, and are the items that are version controlled, including:
...
Should I build my own openEHR persistence solution?
In most cases it is a bad idea to build your own openEHR persistence solution, since it (like any similar implementation and optimization) takes time away from making clinically more useful things based on some already existing commercial or Open Source openEHR persistence solution. See some existing known alternatives at https://openehr.org/products_tools/platform/.
If however your main (research) interest is advanced storage solutioins, then make sure to read what has already been published about openEHR persistence before you build. In addition to publication search engines (like Google Scholar) the openEHR Zotero Persistence category can be useful.
Is persistence different in openEHR?
The openEHR architecture is different from other architectures in the health domain, and in most domains. The main difference is that it doesn't only have an object model from which to create software, database schemas etc, it also has also a layer of domain models called archetype FAQs. As a consequence, the part of the architecture that is defined as object models (known as the "reference model" or RM) is smaller and more generic than many models. The RM can be considered for most purposes as a typical object model. To get a feel for the architecture, the Architecture Overview is a good place to start.
On one level therefore, persisting openEHR data is no different from persisting data in any object model of an equivalent number of classes (around 100, including all data types, EHR types, demographic types). There are two main challenges:
- bridging the object/relational gap: how to persist object data in relational databases which may be a requirement of the deployment environment
- the query trade-off: in any database, storing and retrieving numerous fine-grained objects is costly in terms of disc access time, yet the finer the granularity of storage, the more likely it is that the database's inbuilt query engine can query the data directly rather than forcing the application to retrieve and process the query itself..
These problems are related in their solution since if we opt for very coarse-grained data storage, the object/relational gap diminishes as well.
How can openEHR data be characterised?
Structure
To understand how to persist openEHR objects, we need to have a feel for the data. The business objects are known as "top-level structures" in openEHR, and are the items that are version controlled, including:
- Compositions (see EHR IM, ehr.composition package; Composition XML-schema)
- Folder structures (see Common IM, common.directory package)
- Ehr_status object in an EHR (see EHR IM, ehr package)
- Party structures in the demographic model, e.g. Person, Role instances (see Demographic IM)
...
The default situation will be that using an O/R product on a typical object model over a relational database will result in numerous tables and extremely fine-grained object storage and retrieval, with the consequent performance penalty. Most likely, an O/R product will not know about business object boundaries and will do the same thing as an object database with a naively designed object model: store and retrieve everything reachable by reference-following. Avoiding these problems means at a minimum reducing the granularity of the objects being stored; see below.Examples of object/relational products include: Apache ObJectRelationalBridge (OJB) for Java and DataObjects.NETthe granularity of the objects being stored; see below.
Examples of object/relational products include: Apache ObJectRelationalBridge (OJB) for Java, Grails ORM and DataObjects.NET.
If instead of using default O/R framework mappings, you make sure the storage method is optimized to openEHR structures and query patterns then it is possible to get reasonable performance also in persistence solutions based on tabular formats and relational algebra, e.g. Hadoop or relational databases. The paper
Relational databases
Object data can be directly stored in a relational database, but the schema design is a greater issue. If the intention is that schema is a derivative of the object model - i.e. the "classical" approach to mapping (typical strategies) then the schema design may not be trivial. This kind of schema design is what many of the O/R tools try to automate and/or hide. However, other strategies are available, including one very interesting one which is possible due to the paths in openEHR data.
...