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

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

RM entity taxonomy
Figure 1. rm.entity taxonomy

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

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

RM entity
Figure 2. rm.entity

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

TBD

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

LOCATABLE

Attributes

Signature

Meaning

0..1

description: CLUSTER

Archetypable generic description for this entity.

0..1

type_uri: 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 PERSON might be used to represent Employees. This field might then contain a URI pointing to the relevant description of 'employee' within the owning organisation.

0..1

relationships: List<RELATIONSHIP_GROUP>

Functions

Signature

Meaning

1..1

type (): Terminology_term

Concrete type of entity, such as PERSON, ORGANISATION, etc. Role name, e.g. general practitioner , nurse , private citizen . Taken from inherited name attribute.

3.4.2. ENTITY_RELATIONSHIP Class

Class

ENTITY_RELATIONSHIP (abstract)

Description

Inherit

LOCATABLE

Attributes

Signature

Meaning

1..1

source: String

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

1..1

type: Terminology_term

Type of relationship, such as employment, authority, health provider.

1..1

target: String

Target of relationship.

0..1

time_validity: Interval<Iso8601_date>

Valid time interval for this relationship.

0..1

description: CLUSTER

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 type may have values like 'parts', 'employees' and so on.

Attributes

Signature

Meaning

0..1

members: List<String>

Individual relationships within this group (type).

1..1

type: Terminology_term

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.

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

4.3. Semantics

4.3.1. Biological Entities

xxx

4.3.2. Artefacts

xxx

4.3.3. Substances

xxx

4.3.4. Sites and Facilities

xxx

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 BFO::Independent Continuant, except that Spatial regions are excluded.

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

ENTITY

4.4.2. MATERIAL_ENTITY Class

Class

MATERIAL_ENTITY (abstract)

Description

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

Inherit

MATERIALLY_DEPENDENT_ENTITY

Attributes

Signature

Meaning

0..1

r_parts: List<MATERIAL_ENTITY>

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

PHYSICAL_ENTITY

Attributes

Signature

Meaning

0..1

r_contains: List<MATERIALLY_DEPENDENT_ENTITY>

4.4.4. SPATIAL_REGION Class

Class

SPATIAL_REGION (abstract)

Description

Equivalent to BFO:Spatial region.

Inherit

PHYSICAL_ENTITY

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 BFO:Site.

Inherit

OBJECT_EXTENSION_PART

Attributes

Signature

Meaning

1..1

r_located_in: MATERIAL_ENTITY

0..1
(redefined)

r_parts: List<SPACE>

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

SPACE

Attributes

Signature

Meaning

0..1

r_facilities: List<FACILITY>

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

OBJECT_AGGREGATE

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

r_members: List<MATERIAL_ENTITY>

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
(redefined)

r_parts: List<OBJECT_AGGREGATE>

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

MATERIAL_ENTITY

Attributes

Signature

Meaning

0..1
(redefined)

r_parts: List<OBJECT_EXTENSION_PART>

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

OBJECT_EXTENSION_PART

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:

  • living organisms;

  • deceased organisms;

  • body parts;

  • tissue, including blood;

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

INDEPENDENT_OBJECT

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

INDEPENDENT_OBJECT

Attributes

Signature

Meaning

1..1

function: @@

Purpose of the artefact.

4.4.13. SUBSTANCE Class

Class

SUBSTANCE

Description

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

Inherit

INDEPENDENT_OBJECT

4.5. Instance Examples

xxx.

4.5.1. Biological Entities

4.5.1.1. Tissue Sample

xxx.

tissue sample
Figure 4. Biological Entity

4.5.2. Artefacts

4.5.2.1. Ultrasound Machine
4.5.2.2. Cardiac Pacemaker

4.5.3. Substances

4.5.3.1. Medication
4.5.3.2. Food

4.5.4. Aggregate objects

xxx

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

ENTITY

Attributes

Signature

Meaning

0..1

r_physical_bearer: PHYSICAL_ENTITY

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.

RM entity.social entity.party
Figure 5. 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 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 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.

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

accountability_types: List<ACCOUNTABILITY>

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

r_assets: List<ASSET>

Assets of a Party.

0..1

r_services: List<SERVICE>

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

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 BFO:Role.

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.

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 BFO:Capability, a proposed category between Disposition and Function in BFO.

Inherit

PARTY

Invariants

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

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

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 , stage name, nickname, tribal name, trading name. Taken from value of inherited name attribute.

Invariants

Purpose_valid: purpose = name

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

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

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

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.

6.4.8. AGGREGATE_AGENT Class

Class

AGGREGATE_AGENT (abstract)

Description

An aggregate of multiple parties, that acts as a single agent.

Inherit

AGENT

Attributes

Signature

Meaning

1..1

purpose: @@

0..1

r_members: List<INDIVIDUAL_AGENT>

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

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 physical_bearer a Facility.

Inherit

AGGREGATE_AGENT

Attributes

Signature

Meaning

0..1

r_parts: List<ORG_UNIT>

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

ORG_ENTITY

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

ORG_ENTITY

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

AGENT

6.4.13. AUTOMATON Class

Class

AUTOMATON

Description

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

Inherit

INDIVIDUAL_AGENT

6.4.14. PERSON Class

Class

PERSON

Description

A human agent.

Inherit

INDIVIDUAL_AGENT

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

ENTITY_RELATIONSHIP

Attributes

Signature

Meaning

0..1

scoper: String

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

1..1
(redefined)

source: String

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

1..1
(redefined)

target: String

Target of relationship.

Invariants

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

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

Type_validity: type = name

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.2. Clinician
6.5.1.3. Credentials
6.5.1.4. Health Care Facility
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).

6.5.2. Relationships

6.5.2.1. Familial Relationship
6.5.2.2. Employment Relationship
6.5.2.3. Patient

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

7. Asset Package

7.1. Overview

xxx

RM entity.social entity.asset
Figure 6. rm.entity.social_entity.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

SOCIAL_ENTITY

7.2.2. EQUIPMENT Class

Class

EQUIPMENT

Description

Capital equipment asset, including machines and devices, used by a Party.

Inherit

ASSET

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

ASSET

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 physical_bearer of type Geographical Site or Facility.

Inherit

ASSET

Attributes

Signature

Meaning

0..1

addresses: List<ADDRESS>

Addresses of a Place within one or more address spaces.

7.2.5. SERVICE Class

Class

SERVICE

Description

A business level service provided by a Party.

TBD: detail.

Inherit

SOCIAL_ENTITY

7.3. Semantics

7.3.1. Service

A Service is understood as a standardised offering of a Party, generally consisting of a combination of Assets and Parties required to effect an instance of the Service.

7.4. Instance Examples

xxx.

7.4.1. Property

xxx.

7.4.2. Equipment

xxx.

7.4.3. Consumables

xxx.

7.4.4. Service: Dialysis

xxx

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.

RM entity.resource
Figure 7. rm.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

LOCATABLE

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: CLUSTER

Cost data for this resource use.

0..1

description: CLUSTER

Detailed description of this resource utilisation.

0..1

resource: List<ENTITY>

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

RESOURCE_USE

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

RESOURCE_USE

Attributes

Signature

Meaning

1..1

amount: @@

Amount of resource consumed.

8.3. Instance Examples

xxx.

8.3.1. Biological Entities

8.3.1.1. XXX

xxx.

8.3.2. Artefacts

xxx

8.3.3. Substances

xxx

8.3.4. Aggregate objects

xxx

9. Registry Package

9.1. Overview

xxx

RM entity.registry
Figure 8. rm.entity.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: 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.

0..1

resource_uses: Hash<OBJECT_REF,VERSIONED_RESOURCE_USE>

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 VERSIONED_OBJECT<T> to ENTITY.

Inherit

VERSIONED_OBJECT

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

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

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

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