| access_control | The rm.security.access_control package. | |
| am | The openEHR am package contains the models necessary to describe the semantics of archetypes and templates, and their use within openEHR. These include ADL, the Archetype Definition Language (expressed in the form of a syntax specification), the archetype and template packages, defining the object-oriented semantics of archetypes and templates, and the openehr_profile package, which defines a profile of the generic archetype model defined in the archetype package, for use in openEHR (and other health computing endeavours). | |
| archetype | ||
| archetype | The archetype service model defines the interface to online repositories of archetypes, and can be used both by GUI applications designed for human browsing as well as access by other software services such as the EHR. | |
| archetyped | The rm.common.archetyped package defines the core types PATHABLE, LOCATABLE, ARCHETYPED, and LINK | |
| assertion | Assertions are expressed in archetypes in typed first-order predicate logic (FOL). They are used in two places: to express archetype slot constraints, and to express invariants in complex object con- straints. In both of these places, their role is to constrain something inside the archetype. Constraints on external resources such as terminologies are expressed in the constraint binding part of the arche- type ontology. | |
| assumed | ||
| assumed_types | some Assumed Types for the openEHR Reference Model. | |
| basic | The am.openehr_profile.data_types.basic package defines custom types for constraining the RM state types. | |
| basic | ||
| change_control | As described in the Architecture Overview document, formal version control and change management are used in openEHR to support the construction of EHR and other repositories requiring the properties of consistency, indelibility, traceability and distributed sharing. The rm.common.change_control package supplies the formal specification of these features in openEHR. | |
| common | The common Reference Model comprises a number of packages containing abstract concepts and design patterns used in higher level openEHR models. Several concepts recur in higher level packages. The classes LOCATABLE and ARCHETYPED provide the link between information and archetype models. The classes ATTESTATION and PARTICIPATION are generic domain concepts that appear in various reference models. The change_control package defines a formal model of change management and versioning which applies to any service that needs to be able to supply previous states of its information, in particular the demographic and EHR services. | |
| composition | The rm.composition package. The Composition is the primary data container' in the openEHR EHR and is the root point of clinical content. Instances of the Composition class can be considered as self-standing data aggregations, or documents in a document-oriented system. The key information in a COMPOSITION is found in its content, context, and composer attributes. | |
| constraint_model | The archetype Constraint Model is completely generic, and is designed to express the semantics of constraints on instances of classes which are themselves described in UML (or a similar object-oriented meta-model). Accordingly, the major abstractions in this model correspond to major abstractions in object-oriented formalisms, including several variations of the notion of object' and the notion of attribute'. The notion of object' rather than class' or type' is used because archetypes are about constraints on data (i.e. instances', or objects') rather than models, which are constructed from classes'. | |
| content | The content package contains the CONTENT_ITEM class, ancestor class of all content types, and the navigation and entry packages, which contain SECTION, ENTRY and related types. | |
| data_structures | In most openEHR information models, generic data structures are used for expressing content whose particular structure will be defined by archetypes. The generic structures are as follows. Single: single items, used to contain any single value, such as a height or weight. List: linear lists of named items, such as many pathology test results. Table: tabular data, including unlimited and limited length tables with named and ordered columns, and potentially named rows. Tree: tree-shaped data, which may be conceptually a list of lists, or other deep structure. History: time-series structures, where each time-point can be an entire data structure of any complexity, described by one of the above structure types. Point and interval samples are supported. | |
| data_types | ||
| data_types | A set of clearly defined data types underlies all other models, and provides a number of general and clinically specific types required for all kinds of health information. The following categories of data types are defined in the data types reference model. Text: plain text, coded text, paragraphs. Quantities: any ordered type including ordinal values (used for representing symbolic ordered values such as + , ++ , +++ ), measured quantities with values and units, and so on. Date/times: date, time, date-time types, and partial date/time types. Encapsulated data: multimedia, parsable content. Basic types: boolean, state variable. | |
| date_time | ||
| definition | The rm.support.definition package defines symbolic definitions used by the openEHR models. Only a small number are currently defined. | |
| demographic | The demographic model defines generic concepts of PARTY, ROLE and related details such as contact addresses. The archetype model defines the semantics of constraint on PARTYs, allowing archetypes for any type of person, organisation, role and role relationship to be described. This approach provides a flexible way of including the arbitrary demographic attributes allowed in the OMG HDTF PIDS standard. | |
| demographic | ||
| directory | The rm.common.directory package provides a simple abstraction of a versioned folder structure. | |
| ehr | The EHR IM defines the containment and context semantics of the concepts EHR, COMPOSITION, SECTION, and ENTRY. These classes are the major coarse-grained components of the EHR, and correspond directly to the classes of the same names in CEN EN13606:2005 and fairly closely to the levels of the same names in the HL7 Clinical Document Architecture (CDA) release 2.0. | |
| ehr | The EHR service model defines the coarse-grained interface to electronic health record service. The level of granularity is openEHR Contributions and Compositions, i.e. a version-control / change-set interface. Part of the model defines the semantics of server-side querying, i.e. queries which cause large amounts of data to be processed, generally returning small aggregated answers, such as averages, or sets of ids of patients matching a particular criterion. | |
| ehr_extract | The EHR Extract IM defines how an EHR extract is built from COMPOSITIONs, demographic, and access control information from the EHR. A number of Extract variations are supported, including full openEHR , a simplified form for integration with CEN EN13606, and an openEHR/openEHR synchronisation Extract. | |
| encapsulated | The data_types.encapsulated package contains classes representing data values whose internal structure is defined outside the EHR model, such as multimedia and parsable data. | |
| entry | The rm.composition.content.entry package. All information which is created in the openEHR health record is expressed as an instance of a class in the entry package, containing the ENTRY class and a number of descendants. An ENTRY instance is logically a single clinical statement', and may be a single short narrative phrase, but may also contain a significant amount of data, e.g. an entire microbiology result, a psychiatric examination, a complex prescription. In terms of actual content, the Entry classes are the most important in the openEHR EHR Information Model, since they define the semantics of all the hard' information in the record. They are intended to be archetyped, and in fact, archetypes for Entries make up the vast majority of important clinical archetypes defined. | |
| generic | The classes presented in the "rm.common.generic" package are abstractions of concepts which are generic patterns in the domain of health (and most likely other domains), such as participation' and attestation'. | |
| history | ||
| identification | The rm.support.identification package describes a model of references and identifiers for information entities. | |
| integration | The Integration model defines the class GENERIC_ENTRY, a subtype of ENTRY used to represent free-form legacy or external data as a tree. This Entry type has its own archetypes, known as integration archetypes , which can be used in concert with clinical archetypes as the basis for a tool-based data integration system. | |
| item_structure | ||
| measurement | The rm.support.measurement package defines a minimum of semantics relating to quantitative measurement, units, and conversion, enabling the Quantity package of the openEHR Data Types Information Model to be correctly expressed. As for the Terminology package, a simple service interface is assumed, which provides useful functions to other parts of the reference model. | |
| navigation | The rm.composition.content.navigation Package defines a hierachical heading structure, in which all individual headings are considered to belong to a tree of headings . Each heading is an instance of the class SECTION. | |
| ontology | All linguistic and terminological entities in an archetype are represented in the ontology part of an archetype, whose semantics are given in the Ontology package | |
| openehr | The openEHR Foundation - see http://www.openehr.org | |
| openEHR 1.0.1 - draft | openEHR Specification Release 1.0.1 | |
| openehr_profile | The openEHR Archetype Profile is used to define custom archetype classes and in some cases, custom syntax equivalents (essentially shorthands) that can be used instead of the AOM generic classes for archetyping certain RM classes. The internal structure of the package mimics the structure of the reference model it profiles, i.e. the openEHR reference model. This is done to make software development easier, even though the package structure may be sparsely populated. Packages need only be defined where there are custom types to be defined; the only ones currently defined are in the data_types package. | |
| operational_template | ||
| org | International top level | |
| primitive | Ultimately any archetype definition will devolve down to leaf node constraints on instances of primitive types. The primitive package defines the semantics of constraint on such types. | |
| quantity | The rm.data_types.quantity package. | |
| quantity | The am.openehr_profile.data_types quantity package defines custom types for constraining the RM quantity types DV_QUANTITY, DV_QUANTITY_ITEM, DV_ORDINAL. | |
| representation | The rm.data_structures.representation package contains classes for a simple hierarchical representation of any data structure. These classes are compatible with the CEN EN13606 classes of the same names, and instances can be losslessly generated to and from EN13606 instances structures. | |
| resource | The rm.common.resource package defines the structure and semantics of the general notion of an online resource which has been created by a human author, and consequently for which natural language is a factor. | |
| rm | The openEHR Reference Model Release 1.0.1 | |
| security | The Security Information Model defines the semantics of access control and privacy setting for information in the EHR | |
| sm | ||
| support | The rm.support package describes the most basic concepts, required by all other packages, and is comprised of the Definitions, Identification, Terminology and Measurement packages. The semantics defined in these packages allow all other models to use identifiers and to have access to knowledge services like terminology and other reference data. The support package includes the special package assumed_types, describing what basic types are assumed by openEHR in external type systems; this package is a guide for integrating openEHR models proper into the type systems of implementation technologies. | |
| template | Classes comprising the am.template package. | |
| template_spec | The "specification" form of a template. | |
| terminology | The terminology interface service provides the means for all other services to access any terminology available in the health information environment, including basic classification vocabularies such as ICDx and ICPC, as well as more advanced ontology-based terminologies. Following the concept of division of responsibilities in a system-of-systems context, the terminology interface abstracts the different underlying architectures of each terminology, allowing other services in the environment to access terms in a standard way. The terminology service is thus the gateway to all ontology- and terminology-based knowledge services in the environment, which along with services for accessing guidelines, drug data and other reference data enables inferencing and decision support to be carried out in the environment. | |
| terminology | The rm.support.terminology package contains classes for accessing terminologies and code sets, including the openEHR Support Terminology, from within instances of classes defined in the reference model. The classes shown here would normally be inherited via the classes EXTERNAL_ENVIRONMENT_ACCESS and OPENEHR_DEFINITIONS, although the exact details of how this is done may vary depending on implementation language. | |
| text | The rm.data_types.text package contains classes for representing all textual values in the health record, including plain text, coded terms, and narrative text. | |
| text | The am.openehr_profile.data_types.text package defines custom types for constraining the corresponging RM type. | |
| time_specification | Time specification is about potentiality rather than actuality, and needs its own types. The openEHR data_types.time_specification package provides such types, based on the HL7 types of the same names | |
| uri | The data_types.uri package includes two types used for referring to information resources. The DV_URI type allows data values which are references to objects on the world wide web to be created. Its specialisation, DV_EHR_URI, enables any element in an openEHR record to be identified in the same way as other objects on the web. The DV_EHR_URI type is convenient, because it is a string, like any other URI, and is therefore easily transportable and processable. Because it has its own scheme space, ehr , instances can be globally unique, as long as EHR identification is globally unique. DV_EHR_URIs are used to express all runtime paths in the EHR. | |
| virtual_ehr | The virtual EHR API defines the fine-grained interface to EHR data, at the level of Compositions and below. It allows an application to create new EHR information, and to request parts of an existing EHR and modify them. This API enables fine-grained archetype-mediated data manipulation. Changes to the EHR are committed via the EHR service. | |
| workflow |