| 164 | | 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. |
| 165 | | EHR Service Model |
| 166 | | |
| 167 | | 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. |
| 168 | | |
| 169 | | 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. |
| 170 | | |
| 171 | | Archetype Service Model |
| 172 | | |
| 173 | | The archetype service model defines the interface to online repositories of archetypes, and can be used both by 5 openEHR Package Structure |
| 174 | | 5.1 Overview |
| 175 | | |
| 176 | | FIGURE 8 illustrates the package structure of the openEHR formal specifications. Three major packages are defined: rm, am and sm. All packages defining detailed models appear inside one of these outer packages, which may also be thought of as namespaces. They are conceptually defined within the org.openehr namespace, which can be represented in UML as further packages. In some implementation technologies (e.g. Java), the org.openehr namespace may actually be used within program texts. |
| 177 | | |
| 178 | | One of the important design aims of openEHR is to provide a coherent, consistent and re-usable type system for scientific and health computing. Accordingly, the `core' of the RM (bottom-most layers) provides identifiers, data types, data structures and various common design patterns that can be re-used ubiquitously in the upper layers of the RM, and equally in the AM and SM packages. FIGURE 9 illustrates the relationships between the packages. Dependencies only exist from higher packages to lower packages. |
| 179 | | |
| 180 | | 5.2 Reference Model (RM) |
| 181 | | |
| 182 | | Each package defines a local context for definition of classes. FIGURE 10 illustrates the RM package structure. An informal division into "domain", "patterns" and "core" is shown. The packages in the latter group are generic, and are used by all openEHR models, in all the outer packages. Together, they provide identification, access to knowledge resources, data types and structures, versioning semantics, and support for archetyping. The packages in the former group define the semantics of enterprise level health information types, including the EHR and demographics. |
| 183 | | |
| 184 | | Each outer package in FIGURE 10 corresponds to one openEHR specification document1, documenting an "information model" (IM). The package structure will normally be replicated in all ITS expressions, e.g. XML schema, programming languages like Java, C# and Eiffel, and interoperability definitions like WSDL, IDL and .Net. |
| 185 | | |
| 186 | | 5.2.1 Package Overview |
| 187 | | |
| 188 | | The following sub-sections provide a brief overview of the RM packages. |
| 189 | | Support Information Model |
| 190 | | |
| 191 | | This 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. |
| 192 | | Data Types Information Model |
| 193 | | |
| 194 | | 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. |
| 195 | | |
| 196 | | * Text: plain text, coded text, paragraphs. |
| 197 | | * Quantities: any ordered type including ordinal values (used for representing symbolic ordered values such as "+", "++", "+++"), measured quantities with values and units, and so on. |
| 198 | | * Date/times: date, time, date-time types, and partial date/time types. |
| 199 | | * Encapsulated data: multimedia, parsable content. |
| 200 | | * Basic types: boolean, state variable. |
| 201 | | |
| 202 | | Data Structures Information Model |
| 203 | | |
| 204 | | 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. |
| 205 | | |
| 206 | | * Single: single items, used to contain any single value, such as a height or weight. |
| 207 | | * List: linear lists of named items, such as many pathology test results. |
| 208 | | * Table: tabular data, including unlimited and limited length tables with named and ordered columns, and potentially named rows. |
| 209 | | * Tree: tree-shaped data, which may be conceptually a list of lists, or other deep structure. |
| 210 | | * 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. |
| 211 | | |
| 212 | | Common Information Model |
| 213 | | |
| 214 | | 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. The key semantics of versioning in openEHR are described in section 8 on page 45. |
| 215 | | Security Information Model |
| 216 | | |
| 217 | | The Security Information Model defines the semantics of access control and privacy setting for information in the EHR. |
| 218 | | EHR Information Model |
| 219 | | |
| 220 | | 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. |
| 221 | | EHR Extract Information Model |
| 222 | | |
| 223 | | 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. |
| 224 | | Integration Information Model |
| 225 | | |
| 226 | | 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. See section 14 on page 79 for more details. |
| 227 | | Demographics Information Model |
| 228 | | |
| 229 | | 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. |
| 230 | | Workflow Information Model (future) |
| 231 | | |
| 232 | | Workflow is the dynamic side of clinical care, and consists of models to describe the semantics of processes, such as recalls, as well as any care process resulting from execution of guidelines. |
| 233 | | 5.3 Archetype Model (AM) |
| 234 | | |
| 235 | | 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). The internal structure of the am package is shown in FIGURE 11. |
| 236 | | |
| 237 | | 5.4 Service Model (SM) |
| 238 | | |
| 239 | | The openEHR service model includes definitions of basic services in the health information environment, centred around the EHR. It is illustrated in FIGURE 12. The set of services actually included will undoubtedly evolve over time, so this diagram should not be seen as definitive. |
| 240 | | Virtual EHR API |
| | 168 | バーチャルEHR APIは細粒度のEHRデータインターフェースを定義しており， |
