Changes between Version 8 and Version 9 of Archtectural Overview Archetypes
- Timestamp:
- Oct 2, 2007, 9:52:49 PM (17 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Archtectural Overview Archetypes
v8 v9 85 85 All nodes within the top-level information structures in the openEHR RM are "archetypable", with certain nodes within those structures being archetype "root points". Each top-level type is always guaranteed to be an archetype root point. Although it is theoretically possible to use a single archetype for an entire top-level structure, in most cases, particularly for COMPOSITION and PARTY, a hierarchical structure of multiple archetypes will be used, via the slot mechanism described above. This allows for componentisation and reusability of archetypes. When hierarchies of archetypes are used for a top-level structure, there will also be archetype root points in the interior of the structure. For example, within a COMPOSITION, ENTRY instances (i.e. OBSERVATIONs, EVALUATIONs etc.) are almost always root points. SECTION instances are root points if they are the top instance in a Section structure; similarly for FOLDER instances within a directory structure. Other nodes (e.g. interior SECTIONs, ITEM_STRUCTURE instances) might also be archetype root points, depending on how archetypes are applied at runtime to data. FIGURE 30 illustrates the application of archetypes and templates to data. 86 86 87 [[Image(archetypinga.gif)]] 88 87 89 10.4 Archetype-enabling of Reference Model Data 88 90 … … 94 96 95 97 The result of the use of archetypes to create data in the EHR (and other systems) is that the structure of data in any top-level object conforms to the constraints defined in a composition of archetypes chosen by a template, including all optionality, value, and terminology constraints. 98 96 99 10.5 Archetypes, Templates and Paths 97 100 … … 99 102 100 103 These paths serve to identify any node in a template or archetype, such as the "diastolic blood pressure" ELEMENT node, deep within a "blood pressure measurement" archetype. Since archetype node identifiers are embedded into data at runtime, archetype paths can be used to extract data nodes conforming to particular parts of archetypes, providing a very powerful basis for querying. Paths can also be constructed into data, using more complex predicates (still in the Xpath style). Paths in openEHR are explained in detail under Paths and Locators on page 63. 104 105 [[Image(archetypingb.gif)]] 106 101 107 10.6 Archetypes and Templates at Runtime 108 102 109 10.6.1 Overview 103 110 104 111 openEHR archetypes and templates were designed as formal artefacts, so as to be computable at runtime. They perform two key functions. The first is to facilitate data validation at data capture or import time, i.e. to guarantee that data conform to not just the reference model, but also to the archetypes themselves. Data validation with archetypes is mediated by the use of openEHR Templates. The second function is as a design basis for queries. Since data are captured based on archetypes, all openEHR data are guaranteed to conform to the "semantic paths" that are created by the composition of archetypes within a template. The paths (such as those shown in FIGURE 31 above) are incorporated within a familiar SQL-style syntax, to form queries that can be evaluated to retrieve items on a semantic basis. 112 105 113 10.6.2 Deploying Archetypes and Templates 106 114 … … 123 131 The deployment of archetypes, templates, and screen forms is shown in FIGURE 32. 124 132 133 134 [[Image(archetyping4.gif)]] 135 125 136 10.6.3 Validation during Data Capture 126 137 … … 130 141 131 142 The actual process of data creation and committal is illustrated in FIGURE 33. The essence of the process is that a "kernel" component performs the task of data creation and validation by maintaining a "template space" and a "data space". The former contains the template and archetypes retrieved due to a screen form being displayed; the latter contains the data structures (instances of the openEHR reference model) that are constructed due to user activity on the screen. When data are finally committed, they are guaranteed to conform to the template/archetype definitions, due to the checks that are made each time the user tries to change the data structure. The committed data contain a "semantic imprint" of the generating archetypes, in the form of archetype node identifiers on every node of the data. This simple inclusion in the data model ensures that all archetypes data are queryable by the use of archetype paths. In XML representations, the archetype node ids are represented as XML attributes (i.e. inside the tag), thus enabling XPaths to be conveniently navigated through the data based on these identifiers (more details on this are in the next section). 143 144 145 [[Image(archetyping3.gif)]] 132 146 133 147 If data are later modified, they are brought into the kernel along with the relevant template and archetypes, and the embedded node identifiers allow the kernel to continue to perform appropriate checking of changes to the data.
