openEHR logo

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

openEHR components
© 2022 - 2022 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

image Creative Commons Attribution-NoDerivs 3.0 Unported. https://creativecommons.org/licenses/by-nd/3.0/

Support

Issues: Problem Reports
Web: specifications.openEHR.org

Amendment Record

Issue Details Raiser Completed

RM Release 1.?.?

0.3.0

SPECRM-?: Initial writing; adapted from Demographic IM.

T Beale

15 Oct 2022

Acknowledgements

Editor

  • Thomas Beale, Ars Semantica (UK); openEHR Foundation Management Board.

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

Support

The work reported in this paper has been funded in part by the following organisations:

  • Ars Semantica (UK).

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.

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. Entity Model

2.1. 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 upper level of the Entity model.

RM entity overview
Figure 1. rm.entity package

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.1.1. 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

2.1.2. Identification

Technical identifiers of Entity instances are represented via the uid attribute (type OBJECT_VERSION_ID) of the containing VERSION. These identifiers are used in all cross-references between Entities.

To Be Continued

3. Physical Entity Package

3.1. 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.

RM entity.physical entity
Figure 2. rm.entity.physical_entity package

3.2. Class Definitions

3.2.1. PHYSICAL_ENTITY Class

Class

PHYSICAL_ENTITY (abstract)

Description

Purely physical entities, in the realist sense of BFO. Includes material entities (entities consisting of matter) and physical entities corresponding to voids, spaces and spatial extents.

Equivalent to bfo::Entity.

Inherit

ENTITY

3.2.2. MATERIAL_ENTITY Class

Class

MATERIAL_ENTITY (abstract)

Description

Any entity consisting of physical matter. Synonym for bfo:Material entity.

Inherit

PHYSICAL_ENTITY

3.2.3. OBJECT_AGGREGATE Class

Class

OBJECT_AGGREGATE

Description

Synonym for bfo:Object aggregate. Member parts are causally independent Entities - either more Object aggregates, or else Independent objects.

Inherit

MATERIAL_ENTITY

Attributes

Signature

Meaning

0..1

parts: List<MATERIAL_ENTITY>

Containment relation of an aggregate (non-primitive) object.

3.2.4. INDEPENDENT_OBJECT Class

Class

INDEPENDENT_OBJECT (abstract)

Description

Synonym for bfo:object ('Object' is generally a problematic term in a class model, hence 'independent object'). Understood as a causally independent / unified object, following BFO.

Inherit

MATERIAL_ENTITY

3.2.5. BIOLOGICAL_ENTITY Class

Class

BIOLOGICAL_ENTITY

Description

Any entity containing DNA and/or RNA and primarily considered as an organism (rather than an object), including living organisms, deceased organisms, body parts, tissue, blood, food items (meat, vegetables, fruit), bacteria and viruses.

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. 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

INDEPENDENT_OBJECT

3.2.6. 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, heart pacemaker) 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

INDEPENDENT_OBJECT

Attributes

Signature

Meaning

1..1

function: @@

Purpose of the artefact.

3.2.7. SUBSTANCE Class

Class

SUBSTANCE

Description

Undifferentiated (portion of) material of any kind,including pure elemental materials (e.g. oxygen), compounds, complex molecular substances (e.g. albumin), admixtures, medicines etc.

Inherit

INDEPENDENT_OBJECT

3.3. Instance Examples

xxx.

3.3.1. Biological Entities

3.3.1.1. Tissue Sample

xxx.

tissue sample
Figure 3. Biological Entity

3.3.2. Artefacts

3.3.2.1. Ultrasound Machine
3.3.2.2. Cardiac Pacemaker

3.3.3. Substances

3.3.3.1. Medication
3.3.3.2. Food

3.3.4. Aggregate objects

xxx

4. Social Entity Package

4.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.

4.2. Class Definitions

4.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

ENTITY

Attributes

Signature

Meaning

0..1

physical_bearer: PHYSICAL_ENTITY

Physical bearer of this Social entity.

5. Party Package

5.1. Overview

A Party is a kind of Social entity corresponding to an autonomous Agent, or a particular Persona thereof. Agent is understood as a 'real' social entities with agency, in and of itself, while a Persona is a particular personality of an Agent, based on 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.

RM entity.social entity.party
Figure 4. rm.entity.social_entity.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 responsbility of one Party to another in the relationship.

5.2. Party Identities and Contacts

TODO: old text; review

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).

5.3. Party Relationships and Accountability

Relationships between parties in the real world may be expressed using PARTY_RELATIONSHIP objects, as illustrated below.

Relationships are considered directional, hence the use of the attribute names source and target, however, these names are otherwise neutral, and give no indication as to the meaning of the relationships, such as which party is responsible and which accountable (for comparison, see the demographic models of Fowler (Fowler, 1997)). Accordingly, each Party involved in a relationship includes it in its relationships list, if it is at the source end, or in the reverse_relationships list, if at the target end.

The usual way to determine the directionality of a relationship between two Parties is usually by which Party’s actions caused the relationship to come into being. For example, a relationship representing the concept "patient", between a health consumer and a health care organisation would have the consumer as source and the organisation as target.

PARTY_RELATIONSHIPs are stored as part of the data of the PARTY designated as the source. This means that the relationships attribute is by value, while reverse_relationships is by references, as are PARTY_RELATIONSHIP.source and target. The actual kind of reference is via the use of OBJECT_REFs containing HIER_OBJECT_IDs to denote the Version container of a Party, rather than OBJECT_VERSION_IDs, which would denote particular versions. Logically this implements the semantic that such relationships in the real world are between continuants, i.e. the real Parties, not just one of their version instances in a demographic system.

5.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.

5.4. Class Definitions

5.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 BFO:Realizable entity, i.e. an s-dependent continuant whose bearer is some physical entity - e.g. a material person, or an aggregate of persons making up a 'company'.

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

SOCIAL_ENTITY

Attributes

Signature

Meaning

0..1

identities: List<PARTY_IDENTITY>

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: List<CONTACT>

Contacts for this party.

0..1

relationships: List<PARTY_RELATIONSHIP>

Relationships in which this Party takes part as source.

1..1

legal_status: @@

Legal status of this entity, potentially supported by documentation (references).

TODO: detail

0..1

capabilities: List<CAPABILITY>

Capabilities of this Party.

0..1

accountabilities: List<ACCOUNTABILITY>

Set of accountabilities defined by this Party. For an Organisation, may be understood as organisational posts, i.e. available jobs.

Invariants

Type_valid: type = name

Contacts_valid: contacts /= Void implies not contacts.is_empty

Relationships_validity: relationships /= Void implies (not relationships.is_empty and then relationships.for_all (r | r.source = self)

Reverse_relationships_validity: reverse_relationships /= Void implies (not reverse_relationships.empty and then reverse_relationships.for_all (item | repository ("demographics").all_party_relationships.has_object (item) and then repository("demographics").all_party_relationships.object (item).target = self))

Is_archetype_root: is_archetype_root

Uid_mandatory: uid /= Void

5.4.2. AGENT Class

Class

AGENT (abstract)

Description

An intentional 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.

Inherit

PARTY

Attributes

Signature

Meaning

0..1

languages: List<Terminology_term>

Languages which can be used to communicate with this actor, in preferred order of use (if known, else order irrelevant).

0..1

personae: List<PERSONA>

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.

5.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 scope is the same Accountability.

May be understood as a BFO:Capability, a proposed category between Disposition and Function.

Inherit

PARTY

Invariants

Capabilities_validity: capabilities /= null and not capabilities.is_empty()

5.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

LOCATABLE

Attributes

Signature

Meaning

1..1

description: CLUSTER

The value of the identity. This will usually take the form of a small structure of strings.

Functions

Signature

Meaning

1..1

purpose (): Terminology_term

Purpose of identity, e.g. legal , stagename, nickname, tribal name, trading name. Taken from value of inherited name attribute.

Invariants

Purpose_valid: purpose = name

5.4.5. CONTACT Class

Class

CONTACT

Description

Description of a means of contact of a Party. Actual structure is archetyped.

Inherit

LOCATABLE

Attributes

Signature

Meaning

1..1

addresses: List<ADDRESS>

A set of address alternatives for this contact purpose and time validity combination.

0..1

time_validity: Interval<Iso8601_date>

Valid time interval for this contact descriptor.

Functions

Signature

Meaning

1..1

purpose (): Terminology_term

Purpose for which this contact is used, e.g. mail, daytime phone, etc. Taken from value of inherited name attribute.

Invariants

Purpose_valid: purpose = name

5.4.6. ADDRESS Class

Class

ADDRESS

Description

Address of contact, which may be electronic or geographic.

Inherit

LOCATABLE

Attributes

Signature

Meaning

1..1

description: CLUSTER

Archetypable structured address.

Functions

Signature

Meaning

1..1

type (): Terminology_term

Type of address, e.g. electronic, locality. Taken from value of inherited name attribute.

Invariants

Type_valid: type = name

5.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

LOCATABLE

Attributes

Signature

Meaning

1..1

credentials: CLUSTER

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: Interval<Iso8601_date>

Valid time interval for the credentials of this capability.

5.4.8. AGGREGATE_AGENT Class

Class

AGGREGATE_AGENT (abstract)

Description

An aggregate of multiple parties, that acts as a single mind, and whose agency is an emergent behaviour.

Inherit

AGENT

Attributes

Signature

Meaning

1..1

purpose: @@

0..1

members: List<PARTY>

Simple list of members, if not represented by PARTY.relationships.

5.4.9. 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

AGGREGATE_AGENT

5.4.10. GROUP Class

Class

GROUP

Description

A real world group of Agents constituted for a stated purpose, and whose membership is fully defined, but that is not a legal organisation.

Examples: a cardiac surgery team; marketing department of a company, treasury part of a government.

Inherit

AGGREGATE_AGENT

5.4.11. INDIVIDUAL_AGENT Class

Class

INDIVIDUAL_AGENT (abstract)

Description

An agent that is an indivisible 'single mind' which is the seat of agency.

Inherit

AGENT

5.4.12. AUTOMATON Class

Class

AUTOMATON

Description

A non-human autonomous agent, including robots and AIs.

Inherit

INDIVIDUAL_AGENT

5.4.13. PERSON Class

Class

PERSON

Description

Human being.

Inherit

INDIVIDUAL_AGENT

5.4.14. 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

LOCATABLE

Attributes

Signature

Meaning

1..1

target: PARTY_REF

Target of relationship.

0..1

time_validity: Interval<Iso8601_date>

Valid time interval for this relationship.

1..1

source: PARTY_REF

Source of relationship, may be understood as 'owner' of relationship.

0..1

scoper: ACCOUNTABILITY

The Accountability defining the scope of this relationship; typically a job post.

Functions

Signature

Meaning

1..1

type (): DV_TEXT

Type of relationship, such as employment, authority, health provision

Invariants

Source_valid: source /= Void and then source.relationships.has (self)

Target_valid: target /= Void and then not target.reverse_relationships.has (self)

Type_validity: type = name

5.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.

5.5.1. Parties

5.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.

5.5.1.2. Clinician
5.5.1.3. Credentials
5.5.1.4. Health Care Facility
5.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).

5.5.2. Relationships

5.5.2.1. Familial Relationship
5.5.2.2. Employment Relationship
5.5.2.3. Patient

The figure below shows a simple way of representing the patient relationship between a person and a health care organisation.

6. Asset Package

6.1. Overview

xxx

RM entity.social entity.asset
Figure 5. rm.entity.social_entity.asset package

6.2. Class Definitions

6.2.1. ASSET Class

Class

ASSET (abstract)

Description

Social / business view of one or more physical entities.

Inherit

SOCIAL_ENTITY

6.2.2. EQUIPMENT Class

Class

EQUIPMENT

Description

Capital equipment asset, including machines and devices, used by a Party to achieve its goals.

Inherit

ASSET

6.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

ASSET

6.2.4. PLACE Class

Class

PLACE (abstract)

Description

Locatable place within a geo-spatial address system.

Inherit

ASSET

Attributes

Signature

Meaning

0..1

addresses: List<ADDRESS>

Addresses of a Place within one or more address spaces.

6.2.5. GEOGRAPHICAL_SITE Class

Class

GEOGRAPHICAL_SITE

Description

A geographical site containing (or to contain) built edifices such as a university or hospital.

Inherit

PLACE

Attributes

Signature

Meaning

0..1

facilities: List<FACILITY>

The facilities within a Site; e.g. departments.

6.2.6. FACILITY Class

Class

FACILITY

Description

Building, theatre, ward, room etc normally with a specific business function.

Inherit

PLACE

Attributes

Signature

Meaning

0..1

parts: List<FACILITY>

Sub-parts of a facility, e.g. wards, operating rooms within the orthopedic department.

6.3. Instance Examples

xxx.

6.3.1. Places

xxx.

6.3.2. Equipment

xxx.

6.3.3. Consumables

xxx.

7. Resource Package

7.1. Overview

This section describes the entity.resource package within the openEHR Entity model. Conceptually an Asset is a usable Entity, while a Resource is the utilisation of one or more Entities, and may include cost information, and data relating to service or consumption of the Entities.

RM entity.resource
Figure 6. rm.entity.resource package

7.2. Class Definitions

7.2.1. RESOURCE_ITEM Class

Class

RESOURCE_ITEM (abstract)

Description

Abstract ancestor of Resource classes.

Inherit

LOCATABLE

7.2.2. RESOURCE_PACKAGE Class

Class

RESOURCE_PACKAGE

Description

Package of Resources, that may include other packages.

Inherit

RESOURCE_ITEM

Attributes

Signature

Meaning

0..1

resources: List<RESOURCE>

Resources in this package.

0..1

packages: List<RESOURCE_PACKAGE>

Sub-packages of this package.

7.2.3. RESOURCE Class

Class

RESOURCE

Description

An description of how to use one or more real Entities for a purpose within the context of some work process.

Inherit

RESOURCE_ITEM

Attributes

Signature

Meaning

0..1

entities: List<ENTITY>

Real world entity that is used as a resource in some work context.

0..1

utilisations: List<RESOURCE_USE>

Descriptions of ways to use an Entity as a Resource.

7.2.4. 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.

Attributes

Signature

Meaning

1..1

start_time: Iso8601_date_time

Time at which resource use commenced.

0..1

duration: Iso8601_duration

Duration of resource use.

0..1

cost_data: ITEM_STRUCTURE

Cost data for this resource use.

0..1

description: ITEM_STRUCTURE

Detailed description of this resource.

7.2.5. 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

RESOURCE_USE

7.2.6. 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

RESOURCE_USE

Attributes

Signature

Meaning

1..1

amount: @@

Amount of resource consumed.

7.3. Instance Examples

xxx.

7.3.1. Biological Entities

7.3.1.1. XXX

xxx.

7.3.2. Artefacts

xxx

7.3.3. Substances

xxx

7.3.4. Aggregate objects

xxx

8. Registry Package

8.1. Overview

xxx

RM entity.registry
Figure 7. rm.entity.registry package

8.2. Class Definitions

8.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: Hash<OBJECT_REF,VERSIONED_ENTITY>

0..1

folders: Hash<UUID,VERSIONED_FOLDER>

Folders, used for classifying / grouping other entities.

0..1

material_entities: Hash<OBJECT_REF,VERSIONED_MATERIAL_ENTITY>

Collection of material entities, i.e. 'things'.

0..1

assets: Hash<OBJECT_REF,VERSIONED_ASSET>

Collection of assets, i.e. owned entities.

0..1

parties: Hash<OBJECT_REF,VERSIONED_PARTY>

Collection of parties.

0..1

resources: Hash<OBJECT_REF,VERSIONED_RESOURCE_ITEM>

Collection of resources.

8.2.2. VERSIONED_ENTITY Class

Class

VERSIONED_ENTITY

Description

Static type formed by binding generic parameter of VERSIONED_OBJECT<T> to ENTITY.

Inherit

VERSIONED_OBJECT

8.2.3. VERSIONED_MATERIAL_ENTITY Class

Class

VERSIONED_MATERIAL_ENTITY

Description

Static type formed by binding generic parameter of VERSIONED_OBJECT<T> to ENTITY.

Inherit

VERSIONED_OBJECT

8.2.4. VERSIONED_PARTY Class

Class

VERSIONED_PARTY

Description

Static type formed by binding generic parameter of VERSIONED_OBJECT<T> to ENTITY.

Inherit

VERSIONED_OBJECT

8.2.5. VERSIONED_ASSET Class

Class

VERSIONED_ASSET

Description

Static type formed by binding generic parameter of VERSIONED_OBJECT<T> to ENTITY.

Inherit

VERSIONED_OBJECT

8.2.6. VERSIONED_RESOURCE_ITEM Class

Class

VERSIONED_RESOURCE_ITEM

Description

Static type formed by binding generic parameter of VERSIONED_OBJECT<T> to ENTITY.

Inherit

VERSIONED_OBJECT

References

Fowler, M. (1997). Analysis Patterns: Reusable Object Models. Addison Wesley.