...
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 databasetarget 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.
...
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 archetypes archetype FAQs. As a consequence, the 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 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 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 databasesdatabase's inbuilt query engine can query the data directly rather than forcing the application to retrieve and process the query itself..
...
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)
Each of these types is equivalent to a document in the sense that it defines the level of granularity of store and retrieve from a service. None of the top-level structure types contain any "live" references to objects outside its own hierarchy. This means that a "store" operation on such an object will cause only that object hierarchy to be stored.Changing the interior parts of such object is generally done by retrieving the whole thing and modifying it in memory, then committing the changed version. The real question of interest with respect to how data are pesisted is to do with querying rather than the store/retrieve/modify/store cycle.
The following figure illustrates typical openEHR data and the scope of archetyping and templating.
...
Where openEHR data differs from most other object data is that it is archetyped, meaning that contains archetype node identifiers in every data node (archetype_node_id attribute inherited from LOCATABLE class). FurtherFurther, every node (descendant of LOCATABLE) has a unique name attribute (also inherited from LOCATABLE). These attributes guarantee that an Xpath-style path can be defined for every single node in openEHR data, to the leaf ELEMENTs (the ELEMENT holds a DATA_VALUE instance). See the Architecture Overview for for a detailed explanation.
All openEHR data contains two node identifiers - archeytpe_node_id and name, both inherited from the LOCATABLE class. These enable the creation of Xpath-style paths that can be used to uniquely identify every node in a data composition (see the openEHR Architecture Overview for details on paths). However, these paths differ from Xpath paths in that they carry the node meanings from archetypes, not just the reference model attribute names as typical Xpaths do. For example, consider the following path:
...
How versioning is implemented will have a major impact on the storage approach. Logically, every top-level object in openEHR is versioned, meaning that separate versions from each commit are always available. Further, the Contribution concept means that any particular commit causes a set of versions (often called a "change-set") to be committed in one go. Rolling back to previous states of the data means retrieving the state of the data at each Contribution commit point, not just at arbitrary previous points in time. See the change_control package in the Common IM\.
We also have to be mindful of the requirements of versioned openEHR data - any solution should take account of the following features of openEHR data:
...