Entity Information Model
Issuer: openEHR Specification Program | |
---|---|
Release: RM latest |
Status: DEVELOPMENT |
Revision: [latest_issue] |
Date: [latest_issue_date] |
Keywords: Entity, demographics, reference model, openehr |
© 2022 - 2023 The openEHR Foundation | |
---|---|
The openEHR Foundation is an independent, non-profit foundation, facilitating the sharing of health records by consumers and clinicians via open specifications, clinical models and open platform implementations. |
|
Licence |
Creative Commons Attribution-NoDerivs 3.0 Unported. https://creativecommons.org/licenses/by-nd/3.0/ |
Support |
Issues: Problem Reports |
Amendment Record
Issue | Details | Raiser | Completed |
---|---|---|---|
RM Release 1.?.? |
|||
SPECRM-?: Initial writing; adapted from Demographic IM. |
T Beale |
Acknowledgements
Contributors
This specification benefited from wide formal and informal input from the openEHR and wider health informatics community. The openEHR Foundation would like to recognise the following people for their contributions.
-
Erik Sundvall, Karolinska Institute, Sweden
-
Pablo Pazos, Cabolabs, Uruguay
1. Preface
1.1. Purpose
This document describes the architecture of the openEHR Entity Information Model. The semantics are drawn from the openEHR Demographic Information Model and ontologies, including the Basic Formal Ontology (BFO).
The intended audience includes:
-
Standards bodies producing health informatics standards;
-
Academic groups using openEHR;
-
The open source healthcare community;
-
Solution vendors;
-
Medical informaticians and clinicians interested in health information.
1.2. Related Documents
Prerequisite documents for reading this document include:
Other documents describing related models, include:
1.3. Status
This specification is in the Stable state. The development version of this document can be found at https://specifications.openehr.org/releases/RM/latest/entity.html.
Known omissions or questions are indicated in the text with a 'to be determined' paragraph, as follows:
TBD: (example To Be Determined paragraph)
1.4. Feedback
Feedback may be provided on the openEHR RM specifications forum.
Issues may be raised on the specifications Problem Report tracker.
To see changes made due to previously reported issues, see the RM component Change Request tracker.
1.5. Conformance
Conformance of a data or software artifact to an openEHR specification is determined by a formal test of that artifact against the relevant openEHR Implementation Technology Specification(s) (ITSs), such as an IDL interface or an XML-schema. Since ITSs are formal derivations from underlying models, ITS conformance indicates model conformance.
2. Overview
The openEHR Entity model defines formal representation for various kinds of real world entity, including 'things' such as devices and medicines, biological organisms (including human), as well as all kinds of 'social entity', which includes persons and organisations (parties), in the socio-legal sense, as well as 'assets', i.e. objects as owned and/or used by parties.
Instances of the Entity model correspond to the contents of typical industry repositories for patients, e.g. 'master patient index', 'provider registry', as well as asset registries and many kinds of 'reference data' repositories.
The following UML diagram illustrates the primary taxonomy of the Entity model, with terminal classes (shown in various colours) standing for major categories of real world Entity likely to be recorded in enterprise information systems.
2.1. Ontological Basis
The design of the model is influenced by the Basic Formal Ontology (BFO), a scientific realist ontology widely used in biomedical science and healthcare. The Physical entity part of the model described here follows BFO fairly closely, for the entity types included (i.e. not all BFO is included).
However, we depart from BFO in representing social entities such as Person, Organisation, and Asset, as top-level Entities, rather than 'dependent' entities such as BFO::role
. This primarily because social entities are normally represented as independent entities in IT systems, with their material bearers (a human organism, for Person; the physical premises of a company etc) generally being assumed.
2.2. Conceptual Relations
BFO and related ontologies such as the Relation Ontology define many possible concrete relations between Entities, both between universals (e.g. is-a, continuant-part-of etc.) and between instances (various kinds of parthood etc).
Accordingly, the model shown in this specification includes indicative conceptual relationships between classes (i.e. standing for universals), as a guide to the concrete relationships that may be instantiated at the instance level. These conceptual relations are shown in brown, and have names of the form 'r_xxx'
.
These conceptual relations are intended to be concretely represented using instances of the ENTITY
, ENTITY_RELATIONSHIP
and RELATIONSHIP_GROUP
classes described in the following section.
2.3. Archetyping
The model is designed to be used with archetypes, hence the generic nature of all classes. Every class containing an attribute of the form details:ITEM_STRUCTURE
is a completely archetypable structure. As a result, archetypes can be defined for concepts such as particular kinds of PERSON
, DEVICE
etc., and for many subordinate structures, such as Party identities and addresses.
To Be Continued
3. Upper Entity Model
3.1. Overview
The most general characteristics of Entities are considered to consist of just:
-
the definitional properties of each Entity type;
-
the relationships between them.
The top-level universal Entity is represented by the generic class ENTITY
. Descendants of this class will add properties pertinent to the type it represents.
Indicative conceptual relationships are shown in this model using direct UML associations with names of the form 'r_xxx'
, as explained above. These could be used within software and databases if desired, however, concrete representation is more likely to be achieved by instantiating the relationship classes ENTITY_RELATIONSHIP
and RELATIONSHIP_GROUP
described here.
The following UML diagram illustrates the upper Entity model.
3.2. Semantics
The concrete representation chosen for connecting relationships to owning Entities is intended to facilitate realistic database implementations containing very large numbers (e.g. O(100m)) of Entities, potentially with large numbers of relationships (e.g. O(100)).
ENTITY
instances are accordingly stored only with their related RELATIONSHIP_GROUP
objects, which contain the identifiers of target ENTITY_RELATIONSHIP
objects. This approach allows flexible lazy loading of potentially large structures. It is assumed that the uid
field inherited from LOCATABLE
is used as the identifier for both Entity and Entity Relationship instances.
3.4. Class Definitions
3.4.1. ENTITY Class
Class |
ENTITY (abstract) |
|
---|---|---|
Description |
Continuant Entity whose identity is stable over its period of existence. Includes physical entities as well as other kinds of entities from the social, legal and business worlds, including intentional agents. |
|
Inherit |
||
Attributes |
Signature |
Meaning |
0..1 |
description: |
Archetypable generic description for this entity. |
0..1 |
type_uri: |
URI to a detailed description of the concrete type of Entity represented by instances of any descendant of this class. For example, a specific archetype of |
0..1 |
relationships: |
|
Functions |
Signature |
Meaning |
1..1 |
type (): |
Concrete type of entity, such as |
3.4.2. ENTITY_RELATIONSHIP Class
Class |
ENTITY_RELATIONSHIP (abstract) |
|
---|---|---|
Description |
||
Inherit |
||
Attributes |
Signature |
Meaning |
1..1 |
source: |
Source of relationship, may be understood as 'owner' of relationship. |
1..1 |
type: |
Type of relationship, such as employment, authority, health provider. |
1..1 |
target: |
Target of relationship. |
0..1 |
time_validity: |
Valid time interval for this relationship. |
0..1 |
description: |
Archetypable generic description for this relationship. |
3.4.3. RELATIONSHIP_GROUP Class
Class |
RELATIONSHIP_GROUP |
|
---|---|---|
Description |
Grouping of individual relationships of a given type. The |
|
Attributes |
Signature |
Meaning |
0..1 |
members: |
Individual relationships within this group (type). |
1..1 |
type: |
4. Physical Entity Package
4.1. Issues
-
device 'type' versus device; prosthesis 'type' versus prosthesis etc. Current approach would be to handle via distinct hierarchies of archetypes for Device type and Device.
-
Should OBJECT_AGGREGATE.parts be a collection of ENTITY_REL?
4.2. Overview
Following BFO, openEHR Physical entities are understood as entities found within physical existence, and include material objects of any kind (Material entities); spaces and spatial extents, and processes, including events etc.
4.4. Class Definitions
4.4.1. PHYSICAL_ENTITY Class
Class |
PHYSICAL_ENTITY (abstract) |
|
---|---|---|
Description |
Entities with physical existence, in the realist sense of BFO. Includes material entities (entities consisting of matter) and physical entities corresponding to voids and spaces created by Material entities. Equivalent to Various kinds of Physical Entity may be used to resolve 'anatomical location', i.e. location on the body of an organism, including (following FMA) anatomical spaces (i.e. cavities) and anatomical structures. |
|
Inherit |
4.4.2. MATERIAL_ENTITY Class
Class |
MATERIAL_ENTITY (abstract) |
|
---|---|---|
Description |
Any entity consisting of physical matter. Synonym for |
|
Inherit |
||
Attributes |
Signature |
Meaning |
0..1 |
r_parts: |
Material part-of relation from an object to other material objects that are materially connected, e.g. apartment 3-9 within the apartment block 'Mirabeau' at 32 Av. Bento Loyola, Casamarela, Recife. Excludes contained spaces, sites etc. |
4.4.3. MATERIALLY_DEPENDENT_ENTITY Class
Class |
MATERIALLY_DEPENDENT_ENTITY (abstract) |
|
---|---|---|
Description |
An entity that is either a Material entity or materially depends on a Material entity. |
|
Inherit |
||
Attributes |
Signature |
Meaning |
0..1 |
r_contains: |
4.4.4. SPATIAL_REGION Class
Class |
SPATIAL_REGION (abstract) |
|
---|---|---|
Description |
Equivalent to |
|
Inherit |
4.4.5. SPACE Class
Class |
SPACE (abstract) |
|
---|---|---|
Description |
A three-dimensional Materially-dependent entity that is partially or wholly bounded by a Material Entity. Examples: naturally and partially fiat-defined cavities, holes and spaces. Descendant types provide examples. Similar to |
|
Inherit |
||
Attributes |
Signature |
Meaning |
1..1 |
r_located_in: |
|
0..1 |
Material part-of relation from an object to other material objects that are materially connected, e.g. apartment 3-9 within the apartment block 'Mirabeau' at 32 Av. Bento Loyola, Casamarela, Recife. Excludes contained spaces, sites etc. |
4.4.6. GEOGRAPHICAL_SITE Class
Class |
GEOGRAPHICAL_SITE |
|
---|---|---|
Description |
A geographical site containing (or to contain) built edifices such as a university or hospital. Defined by a boundary, usually found in a civil cadastral system, land register etc. |
|
Inherit |
||
Attributes |
Signature |
Meaning |
0..1 |
The facilities within a Site; e.g. departments. |
4.4.7. FACILITY Class
Class |
FACILITY |
|
---|---|---|
Description |
A physical edifice or part thereof, e.g. a building, theatre, ward, room etc normally with a specific business function. May have as sub-parts other Facilities, e.g. individual rooms. May contain other objects. |
|
Inherit |
4.4.8. OBJECT_AGGREGATE Class
Class |
OBJECT_AGGREGATE |
|
---|---|---|
Description |
Synonym for |
|
Inherit |
||
Attributes |
Signature |
Meaning |
0..1 |
r_members: |
Containment relation between an Object aggregate and other objects located within but not materially part of the aggregate, for example equipment in a room. |
0..1 |
r_parts: |
Material part-of relation from an object to other material objects that are materially connected, e.g. apartment 3-9 within the apartment block 'Mirabeau' at 32 Av. Bento Loyola, Casamarela, Recife. Excludes contained spaces, sites etc. |
4.4.9. OBJECT_EXTENSION_PART Class
Class |
OBJECT_EXTENSION_PART (abstract) |
|
---|---|---|
Description |
Any part of an Object extension, which is an independent object plus any enclosed spaces. |
|
Inherit |
||
Attributes |
Signature |
Meaning |
0..1 |
r_parts: |
Material part-of relation from an object to other material objects that are materially connected, e.g. apartment 3-9 within the apartment block 'Mirabeau' at 32 Av. Bento Loyola, Casamarela, Recife. Excludes contained spaces, sites etc. |
4.4.10. INDEPENDENT_OBJECT Class
Class |
INDEPENDENT_OBJECT (abstract) |
|
---|---|---|
Description |
Synonym for |
|
Inherit |
4.4.11. BIOLOGICAL_ENTITY Class
Class |
BIOLOGICAL_ENTITY |
|
---|---|---|
Description |
Any entity containing DNA and/or RNA and primarily considered as an organism (rather than an object) or part thereof, including:
Note that many objects contain RNA, such as food and most everyday objects on which bacteria can be found, but are not in themselves organisms or considered from a biological point of view. However, in a case of food poisoning determined to have as its source certain food (say, hotel sandwiches), a culture taken from the food and/or human sufferers would be considered a Biological entity. |
|
Inherit |
4.4.12. ARTEFACT Class
Class |
ARTEFACT |
|
---|---|---|
Description |
An artificial (i.e. manufactured) object with a designed function. Encompasses re-usable / long-term use devices (e.g. heart-rate monitor; ultrasound machine, any prosthesis) and consumable items designed to be consumed in use, bandage, catheter, drug, food. A device is considered to be usable until it is determined to be 'worn out' or otherwise not fit for service. This distinguishes it from a consumable, which is considered to be 'used' after one or a small number of uses (the latter situation should be understood as 'one use'). Some consumable items e.g. nasal drip tubes can be physically 'used' more than once with the same patient for a short period of time, but are replaced for different patients and also over longer periods; typically considered consumable. |
|
Inherit |
||
Attributes |
Signature |
Meaning |
1..1 |
function: |
Purpose of the artefact. |
5. Social Entity Package
5.1. Overview
Social entities are understood as entities whose identity, status, type etc are created within the social realm, via legal, commercial or informal social means. Social entities have a physical host of some Physical entity (which may include non-material entities like spaces).
In BFO terms, Social entities roughly correspond to BFO:role
, but for pragmatic reasons, are not considered dependent entities as BFO:role
is, i.e. their material bearers are not usually recorded or of interest.
In this model, Social entities are of two types: Parties and Assets.
5.2. Class Definitions
5.2.1. SOCIAL_ENTITY Class
Class |
SOCIAL_ENTITY (abstract) |
|
---|---|---|
Description |
An entity whose existence and description are within the social world, i.e. civil, business, legal realms. |
|
Inherit |
||
Attributes |
Signature |
Meaning |
0..1 |
r_physical_bearer: |
Physical bearer of this Social entity. |
6. Party Package
6.1. Overview
A Party is a kind of Social entity corresponding either to an autonomous Agent, or a particular Persona thereof. Agent is understood as a 'real' social entity with agency, in and of itself, while a Persona is a particular personality of an Agent, defined by specific Capabilities. For example, the Person Jane Smith may have two Personas: general practitioner (based on her qualifications and registration to practice medicine), and amateur opera singer, based on her singing experience and CV.
The following UML diagram illustrates the party
package.
Parties may generally have identities (i.e. names of various kinds), contact information, legal status and relationships, with the specific kinds of these being dependent upon the kind of Party.
For example, in most cases, only Agents will have identities, which will act as the identities for any Persona the Agent may have. In some cases however, a Persona may have its own Identity, such as a stage or pen name for a Person, or a trading name for a business (Organisation).
Contact information is typically associated both with Agents - corresponding to 'at home', 'citizen' status - and also with Persona, where it is specific to the purpose of the Persona.
Party relationships are how real-world relationships between Parties are represented, including employment, contractual, membership, and other social relationships. Many of these will be based on an Accountability, which describes the responsibility of one Party to another in the relationship.
6.2. Party Identities and Contacts
Parties are characterised by identity,
Classes have been included for PARTY_IDENTITY
and ADDRESS
, even though they contain only a link to details, in the form of the generic ITEM_STRUCTURE
class. This is not strictly necessary - it could have been done simply using appropriately named attributes in the classes PARTY
and CONTACT
- but is done to provide a place to add specific semantics in future releases of the model. It is also expected to make software development easier, since it provides explicit classes to which behaviour and other implementation attributes can be added. Lastly, it allows the notions of PARTY_IDENTITY
and ADDRESS
to be explicitly used in archetype-authoring tools.
Instances of PARTY_IDENTITY
, linked to PARTY
by the attribute identities
are intended to express the names of people, organisations, and other actors - that is names which are "owned" by the party, e.g. self-declared (in the case of institutions and companies) or by virtue of social relations (names given by parents, tribes etc). Identifiers of Parties given by other organisations, or the state are not represented in this way, and should be recorded in the PARTY.details
structure instead (see below).
6.3. Party Relationships and Accountability
Relationships between Parties in the real world may be expressed using PARTY_RELATIONSHIP
instances. Relationships are considered directional, hence the use of the attribute names source
and target
.
A Party Relationship may have a scoper
of type ACCOUNTABILITY
. Accountability types are defined by one Party in the relationship, and are used to represent job posts (formal and informal) and other responsibilities that might be filled by another Party. From the point of view of the Party defining the scope of a Party Relationship, accountabilities are understood as types, since multiple Parties (say, Persons who are software developer) may have the same Accountability (say, 'Python developer').
6.3.1. Versioning Semantics
The class PARTY
and its descendants ACTOR
and ROLE
are all potentially versioned in a demographic system. A Version of a PARTY
includes all the compositional parts, such as identities, contacts, Party relationships of which it is the source. Every Party is stored in its own Version container.
6.4. Class Definitions
6.4.1. PARTY Class
Class |
PARTY (abstract) |
|
---|---|---|
Description |
An independent entity in the social world, often known as a 'party'. Includes all business, civil, military and legal entities. A Social entity is either an Agent or a 'Persona' (of an Agent). An intentional agent can participate in an activity, task, process etc, and make decisions. Theoretically equivalent to However, we tend to treat social entities in business and civic life, and hence administratively and legally, as being independent entities that stand for their bearers. Concretely, we don’t usually represent the related material entity at all. |
|
Inherit |
||
Attributes |
Signature |
Meaning |
0..1 |
identities: |
Identities used by the Party to identify itself. Most commonly, Agents will have identity/ies (at least legal name), but occasionally, a Persona will have identities as well, e.g. stage names, aliases, nicknames. |
0..1 |
Contacts for this party. |
|
1..1 |
legal_status: |
Legal status of this entity, potentially supported by documentation (references). TODO: detail |
0..1 |
capabilities: |
Capabilities of this Party. |
0..1 |
accountability_types: |
Types of formal accountability defined by this Party. For an Organisation, may be understood as organisational post types, i.e. potentially available jobs. |
0..1 |
Assets of a Party. |
|
0..1 |
||
Invariants |
Type_valid: |
|
Contacts_valid: |
||
Relationships_validity: |
||
Reverse_relationships_validity: |
||
Is_archetype_root: |
||
Uid_mandatory: |
6.4.2. AGENT Class
Class |
AGENT (abstract) |
|
---|---|---|
Description |
An intentional real-world agent, equivalent to a mind, either individual or aggregate. An Agent may have one or more Personae, each of which is characterised by one or more Capabilities. Possibly equivalent to |
|
Inherit |
||
Attributes |
Signature |
Meaning |
0..1 |
languages: |
Languages which can be used to communicate with this actor, in preferred order of use (if known, else order irrelevant). |
0..1 |
Personae of an Agent based on Capabilities. A Persona corresponds to the potential to act in a specific capability-based way, i.e. to have a competency or ability. For example, the Person Margaret Smith may have a Persona based on her GP (medical) credentials, and another based on her amateur opera singing Capability. She could therefore work as a GP in a health practice and also as a singer in a drama society. |
6.4.3. PERSONA Class
Class |
PERSONA |
|
---|---|---|
Description |
A particular, coherent social presentation of an Agent, corresponding to one or more Capabilities, and usually having its own Contact information. Example: Dr Jones (a Person) who is a General practitioner (a Persona) works as health centre coordinator (an Accountability) at Park St Health Centre (an Organisation). The employment relationship is the Party relationship whose scoper is the same Accountability. May be understood as a |
|
Inherit |
||
Invariants |
Capabilities_validity: |
6.4.4. PARTY_IDENTITY Class
Class |
PARTY_IDENTITY |
|
---|---|---|
Description |
An identity of a Social entity, such as a person name or company name, and which is used by the party to identify itself. Actual structure is archetyped. |
|
Inherit |
||
Attributes |
Signature |
Meaning |
1..1 |
description: |
The value of the identity. This will usually take the form of a small structure of strings. |
Functions |
Signature |
Meaning |
1..1 |
purpose (): |
Purpose of identity, e.g. legal , stage name, nickname, tribal name, trading name. Taken from value of inherited |
Invariants |
Purpose_valid: |
6.4.5. CONTACT Class
Class |
CONTACT |
|
---|---|---|
Description |
Description of a means of contact of a Party. Actual structure is archetyped. |
|
Inherit |
||
Attributes |
Signature |
Meaning |
1..1 |
A set of address alternatives for this contact purpose and time validity combination. |
|
0..1 |
time_validity: |
Valid time interval for this contact descriptor. |
Functions |
Signature |
Meaning |
1..1 |
purpose (): |
Purpose for which this contact is used, e.g. mail, daytime phone, etc. Taken from value of inherited |
Invariants |
Purpose_valid: |
6.4.6. ADDRESS Class
Class |
ADDRESS |
|
---|---|---|
Description |
Address of contact, which may be electronic or geographic. |
|
Inherit |
||
Attributes |
Signature |
Meaning |
1..1 |
description: |
Archetypable structured address. |
Functions |
Signature |
Meaning |
1..1 |
type (): |
Type of address, e.g. electronic, locality. Taken from value of inherited |
Invariants |
Type_valid: |
6.4.7. CAPABILITY Class
Class |
CAPABILITY |
|
---|---|---|
Description |
Capability of an Agent, such as GP, vascular surgeon. Capability is based on credentials, normally professional certifications. |
|
Inherit |
||
Attributes |
Signature |
Meaning |
1..1 |
credentials: |
The qualifications of the performer of the role for this capability. This might include professional qualifications and official identifications such as provider numbers etc. |
0..1 |
time_validity: |
Valid time interval for the credentials of this capability. |
6.4.8. AGGREGATE_AGENT Class
Class |
AGGREGATE_AGENT (abstract) |
|
---|---|---|
Description |
An aggregate of multiple parties, that acts as a single agent. |
|
Inherit |
||
Attributes |
Signature |
Meaning |
1..1 |
purpose: |
|
0..1 |
r_members: |
Simple list of members, if not represented by |
6.4.9. ORG_ENTITY Class
Class |
ORG_ENTITY (abstract) |
|
---|---|---|
Description |
Any kind of organisational entity that may contain Org units as well as have individual members. An Org Unit may have as its |
|
Inherit |
||
Attributes |
Signature |
Meaning |
0..1 |
Organisational sub-parts. |
6.4.10. ORG_UNIT Class
Class |
ORG_UNIT |
|
---|---|---|
Description |
A unit within an Organisation, constituted for a stated purpose, and which outlives any particular activity it undertakes. Membership is fully defined, and changes over time. An Org unit is not a legal organisation in its own right. Examples: any org unit such as chemistry department of a university; marketing department of a company, treasury part of a government. |
|
Inherit |
6.4.11. ORGANISATION Class
Class |
ORGANISATION |
|
---|---|---|
Description |
A legally constituted body whose existence (in general) outlives the existence of parties that either work for it or own it. Includes public bureaucracies (e.g. UK NHS), companies, joint ventures, multi-national corporations, sports clubs, NGOs. Larger organisations generally have parts which may be internal organisational units, or some other cooperative form of group |
|
Inherit |
6.4.12. INDIVIDUAL_AGENT Class
Class |
INDIVIDUAL_AGENT (abstract) |
|
---|---|---|
Description |
An agent that is an indivisible 'single mind' which is the seat of agency. |
|
Inherit |
6.4.13. AUTOMATON Class
Class |
AUTOMATON |
|
---|---|---|
Description |
A non-human autonomous individual agent, including robots and AIs. |
|
Inherit |
6.4.15. PARTY_RELATIONSHIP Class
Class |
PARTY_RELATIONSHIP |
|
---|---|---|
Description |
A relationship between parties. In BFO terms, a Relational quality, i.e. a Quality that s-depends on the parties of the relation. |
|
Inherit |
||
Attributes |
Signature |
Meaning |
0..1 |
scoper: |
The Accountability type defining the scope of this relationship; typically a job post. |
1..1 |
source: |
Source of relationship, may be understood as 'owner' of relationship. |
1..1 |
target: |
Target of relationship. |
Invariants |
Target_valid: |
|
Source_valid: |
||
Type_validity: |
6.5. Instance Examples
In the following instance examples, the values of the attributes uid, source, target, and reverse_relationships are not meant to be taken as literally valid OBJECT_IDs
- for the purposes of clarity, simple integers have been used.
6.5.1. Parties
6.5.1.1. Person
The diagram below illustrates a possible set of instances for a PERSON
, with home and work contact information. There are separate archetypes for the PERSON
, each ADDRESS
, and each PARTY_IDENTITY
. In the following figure, "meaning" is the meaning from the value of the archetype_node_id attribute, functionally derived from the archetype local ontology.
6.5.1.5. Group
The figure below illustrates the demographic information for a cadiac surgery team in a hospital. The group includes a head surgeon, anaesthetist, assistant surgeon, and presumably others (not shown). Each of these members of the team have an employment relationship with the hospital (shown only for one surgeon, in the interests of clarity).
7. Asset Package
7.2. Class Definitions
7.2.1. ASSET Class
Class |
ASSET (abstract) |
|
---|---|---|
Description |
Social / business view of one or more physical entities that are available as usable assets to a Party. |
|
Inherit |
7.2.2. EQUIPMENT Class
Class |
EQUIPMENT |
|
---|---|---|
Description |
Capital equipment asset, including machines and devices, used by a Party. |
|
Inherit |
7.2.3. CONSUMABLE Class
Class |
CONSUMABLE |
|
---|---|---|
Description |
Assets that are used or consumed in business processes. May be true consumable items like bandages, as well as devices, prostheses, etc that are delivered as part of a procedure. |
|
Inherit |
7.2.4. PROPERTY Class
Class |
PROPERTY |
|
---|---|---|
Description |
A real estate entity used by a Party, either a land area and contained buildings and other facilities, or just a building or part thereof. Normally specified by a street address within the system of the locale (e.g. '72 King St, Hammersmith, London'), and/or via a well-known name (e.g. 'University of Maryland'). Has an associated boundary within a cadastral system defining the land area of the property. May have a |
|
Inherit |
||
Attributes |
Signature |
Meaning |
0..1 |
Addresses of a Place within one or more address spaces. |
8. Resource Package
8.1. Overview
This section describes the entity.resource
package within the openEHR Entity model. Conceptually an Asset is a usable Entity, i.e. a resource. The use of a resource is recorded using the RESOURCE_USE
class and its descendants.
The following illustrates the entity.resource
package.
8.2. Class Definitions
8.2.1. RESOURCE_USE Class
Class |
RESOURCE_USE (abstract) |
|
---|---|---|
Description |
Record of the utilisation of some Entity, in the role of a specific kind of Resource. Archetypes provide models of kinds of use. |
|
Inherit |
||
Attributes |
Signature |
Meaning |
1..1 |
start_time: |
Time at which resource use commenced. |
0..1 |
duration: |
Duration of resource use. |
0..1 |
cost_data: |
Cost data for this resource use. |
0..1 |
description: |
Detailed description of this resource utilisation. |
0..1 |
8.2.2. SERVICE_USE Class
Class |
SERVICE_USE |
|
---|---|---|
Description |
Details of an episode of service corresponding to a single logical 'use' of a re-usable Entity, e.g. a Device or Place. |
|
Inherit |
8.2.3. CONSUMABLE_USE Class
Class |
CONSUMABLE_USE |
|
---|---|---|
Description |
Details of single use and potentially disposal of a consumable artefact. TODO: possibly need to distinguish between strictly consumable things like medication, food, and disposable things like catheters? |
|
Inherit |
||
Attributes |
Signature |
Meaning |
1..1 |
amount: |
Amount of resource consumed. |
9. Registry Package
9.2. Class Definitions
9.2.1. REGISTRY Class
Class |
REGISTRY |
|
---|---|---|
Description |
A logical representation of a repository of versioned Entities of various types. |
|
Attributes |
Signature |
Meaning |
0..1 |
entities: |
|
0..1 |
folders: |
Folders, used for classifying / grouping other entities. |
0..1 |
material_entities: |
Collection of material entities, i.e. 'things'. |
0..1 |
assets: |
Collection of assets, i.e. owned entities. |
0..1 |
parties: |
Collection of parties. |
0..1 |
resources: |
Collection of resources. |
0..1 |
resource_uses: |
Collection of assets, i.e. owned entities. |
9.2.2. VERSIONED_ENTITY Class
Class |
VERSIONED_ENTITY |
|
---|---|---|
Description |
Static type formed by binding generic parameter of |
|
Inherit |
9.2.3. VERSIONED_MATERIAL_ENTITY Class
Class |
VERSIONED_MATERIAL_ENTITY |
|
---|---|---|
Description |
Static type formed by binding generic parameter of |
|
Inherit |
9.2.4. VERSIONED_PARTY Class
Class |
VERSIONED_PARTY |
|
---|---|---|
Description |
Static type formed by binding generic parameter of |
|
Inherit |
9.2.5. VERSIONED_ASSET Class
Class |
VERSIONED_ASSET |
|
---|---|---|
Description |
Static type formed by binding generic parameter of |
|
Inherit |