Composition Package

Overview

The Composition is the primary 'data container' in the openEHR EHR and is the root point of clinical content. Instances of the COMPOSITION class can be considered as self-standing data aggregations, or documents in a document-oriented system. The key information in a COMPOSITION is found in its content, context, and composer attributes. The UML diagram below illustrates the composition package.

RM composition
Figure 1. rm.composition package

Context Model of Recording

Overview

The openEHR EHR model takes account of a systematic analysis of "context". Contexts in the real world are mapped to particular levels of the information model in a clear way, according to the scheme shown in FIGURE 12. On the left hand side is depicted the context of a data-entry session in which the information generated by a "healthcare event", containing "clinical statements", is added to the EHR. A healthcare event is defined as any business activity of the health care system for the patient, including encounters, pathology tests, and interventions. A clinical statement is the minimal indivisible unit of information the clinician wants to record. Clinical statements are shown in the diagram has having temporal and spatial structure as well as data values. Each of these three contexts has its own audit information, consisting of who, when, where, why information.

ehr recording model
Figure 2. General Model of Recording

On the right-hand side of General Model of Recording, the EHR recording environment is represented. The EHR consists of distinct, coarse-grained items known as Compositions added over time and organised by Folders. Each Composition consists of Entries, organised by Sections within the Composition. The audit information for each context is recorded at the corresponding level of the EHR.

Composer

The composer is the person who was primarily responsible for the content of the Composition. This is the identifier that should appear on the screen. It could be a junior doctor who did all the work, even if not legally responsible, or it could be a nurse, even if later attested by a more senior clinician; it will be the patient in the case of patient-entered data. It may or may not be the person who entered and committed the data. it may also be a software agent. This attribute is mandatory, since all content must be been created by some person or agent.

Since in many cases Compositions will be composed and committed by the same person, it might seem that two identifiers COMPOSITION.composer and VERSION.audit.committer (which are both of type PARTY_PROXY) will be identical. In fact, this will probably not be the case, because the kind of identifier to represent the composer will be a demographic identifier, e.g. "RN Jane Williams", "RN 12345678", whereas the identifier in the audit details will usually be a computer system user identifier, e.g. "jane.williams@westmead.health.au". This difference highlights the different purposes of these attributes: the first exists to identify the clinical agent who created the information, while the second exists to identify the logged-in user who committed it to the system.

In the situation of patient-entered data, the special "self" PARTY_PROXY instance (see Common IM generic package) is used for both COMPOSITION.composer and VERSION.audit.committer.

Event Context

Overview

The optional event_context attribute in the COMPOSITION class is used to document the healthcare event causing new or changed content in the record. Here, 'healthcare event' means 'a (generally billable) business activity of the healthcare system with, for or on behalf of the patient'. Generally this will an encounter involving the subject of care and physician, but is variable in a hospital environment. In this sense, a visit to a GP is a single care event, but so is an episode in a hospital, which may encompass multiple encounters. The information recorded in Event context includes start and (optional) end time of the event, health care facility, setting (e.g. primary care, aged care, hospital), participating healthcare professionals, and optional further details defined by an archetype.

Healthcare events that require an EVENT_CONTEXT instance in their recorded information include the following.

  • Scheduled or booked patient encounters leading to changes to the EHR, including with a GP, hospital consultant, or other clinical professional such as mobile nurse. In this case, the Event context documents the time and place of the encounter, and the identity of the clinical professional.

  • Case conferences about a patient, leading to modifications to the health record; here the Event context documents the case conference time, place and participants.

  • Pathology, imaging or other test process. In this case, the Event context documents the place and period during which testing and analysis was carried out, and by whom.

  • Data resulting from care in the home provided by health professional(s) (often allied health care workers). Situations in which Event context is optional include the following.

  • Nurse interactions with patients in hospital, including checking vital signs, adjusting medication or other aspects of bed situation for the patient. Each instance of a nurse’s observations are generally not considered to be a separate 'care event', rather they are seen as the continuation of the general activities of monitoring. In such situations, the overall context is given by ADMIN_ENTRY instances in the record indicating date/time and place of admission and discharge.

Situations in which Event context is not used include:

  • Any modification to the EHR which corrects or updates existing content, including by administrative staff, and by clinical professionals adding or changing evaluations, summaries etc.

  • Patient-entered data where no interaction with health professionals took place; typically readings from devices in the home such as weighing scales, blood glucose measuring devices, wearable monitors etc.

Ultimately, the use of Event context will be controlled by Composition-level archetypes.

Occurrence in Data

For situations requiring an EVENT_CONTEXT object to be recorded, it is worth clarifying which Compositions carry such objects. Consider the example shown in Use of Event context. In this example, a Contribution is made to the EHR, consisting of one or more Compositions that were each created or modified due to some clinical activity. Within such a set, there will usually be one Composition relating directly to the event, such as the patient contact - this is the Composition containing the doctor’s observations, nurses' activities etc, during the visit, and is therefore the one which contains the EVENT_CONTEXT instance. Other Compositions changed during the same event (e.g. updates to medication list, family history and so on) do not require an Event context, since they are part of the same Contribution, and the event context of the primary Composition can always be retrieved if desired. Contributions A, B and C in the figure illustrate this case.

event context
Figure 3. Use of Event context

In cases where Contributions are made to the record with no event context, the Event context of any Compositions from the original commit will remain intact and visible (unless the correction is to the event context itself of course), and will correctly reflect the fact that no new clinical interaction occurred. This is the case with Contribution D in the figure.

Persistent Compositions may optionally have an Event context. In openEHR releases up to 1.0.3, Persistent Compositions had no Event context. This was relaxed in subsequent releases, to allow the inclusion of context information (e.g. encounter data) for changes to Persistent Compositions where no Event Composition was created.

Time

The times recorded in the Event context represent the time of an encounter or other activity undertaken by a health provider to/for/on behalf of the patient. The time is represented as a mandatory start time and optional end time. It is assumed that where there is a clinical session (i.e. an EVENT_CONTEXT object does exist), the start time is known or can be reasonably approximated. It is quite common that the end time of a consultation or encounter is not recorded, but rather inferred from e.g. average consult times, or the start time of the next consult for the same physician.

Event context is used as described above even if the additions are made to the EHR long after the event took place, such as happens when a doctor writes his/her notes into the record system at night, after all patients have been seen. In such cases, the versioned Composition audit trail records the context of when the data were entered, as distinct from the context of when the clinical interaction took place.

Participations

Is part of the Event context, the participations attribute can be used to describe who participated, and how. Each participation object describes the "mode" of participation as well, such as direct presence, video-conference and so on. In many cases such information is of no interest, since the subject of any Entry is known (ENTRY.subject) and the clinician will be known (COMPOSITION.composer), and the mode of communication is assumed to be a personal encounter. The participations attribute is therefore used when it is desired to record further details of how the patient and or physician interacted (e.g. over the internet), and/or other participants, such as family, nurses, specialists etc.

There are no general rules about who is included as a participant. For example, while there will be a patient participation during a GP visit, there will be no such participation recorded when the clinical event is a tissue test in a laboratory. Conversely, a patient might record some observations and drug self-administration in the record, in which case the composer will be the patient, and there will be no clinician participation. Consequently, the use of participations will mostly be archetype-driven.

Healthcare Facility, Location and Setting

The health_care_facility (HCF) attribute is used to record the health care facility in whose care the event took place. This is the most specific identifiable (i.e. having a provider id within the health system) workgroup or care delivery unit within a care delivery enterprise which was involved in the care event. The identification of the HCF can be used to ensure medico-legal accountability. Often, the HCF is also where the encounter physically took place, but not in the case of patient home visits, internet contacts or emergency care; the HCF should not be thought of as a physical place, but as a care delivery management unit. The physical place of care can be separately recorded in EVENT_CONTEXT.location. The health_care_facility attribute is optional to allow for cases where the clinical event did not involve any care delivery enterprise, e.g. self-care at home by the patient, emergency revival by a non-professional (e.g. CPR by lifeguard on a beach), care by a professional acting in an unofficial capacity (doctor on a plane asked to aid a passenger in difficulty). In all other cases, it is mandatory. Archetypes are used to control this.

Two other context attributes complete the predefined notion of event context in the model: location and setting. The location attribute records: the physical location where the care delivery took place, and should document a reasonably specific identifiable location. Examples include "bed 5, ward E", "home". This attribute is optional, since the location is not always known, particularly in legacy data.

The setting attribute is used to document the "setting" of the care event. In clinical record keeping, this has been found to be a useful coarse-grained classifier of information. The openEHR Terminology "setting" group is used to code this attribute. It is mandatory, on the basis that making it optional will reduce its utility for querying and classification.

Composition Content

The data in a Composition is stored in the content attribute. There are four kinds of data structuring possible in the content attribute:

  • it may be empty. Although for most situations, there should be content in a Compostion, there are at least two cases where an empty Composition makes sense:

    • the first is a Composition in 'draft' editing state (VERSION.lifecycle_state = 'incomplete')

    • the second is for systems that are only interested in the fact of an event having taken place, but want no details, such as so-called clinical 'event summary' systems, which might record the fact of visits to the doctor, but contain no further information. This can be achieved using Compositions with event context, and no further content.

  • it may contain one or more SECTIONs which are defined in the archetype of the Composition;

  • it may contain one or more SECTION trees, each of which is a separately archetyped structure;

  • it may contain one or more ENTRYs directly, with no intermediate SECTIONs;

  • it may be any combination of the previous three possibilities.

The actual structures used in a Composition at runtime are controlled by a template, which in turn controls the particular combination of archetypes used.

Class Descriptions

COMPOSITION Class

  • Definition

  • Effective

  • BMM

  • UML

Class

COMPOSITION

Description

Content of one version in a VERSIONED_COMPOSITION. A Composition is considered the unit of modification of the record, the unit of transmission in record Extracts, and the unit of attestation by authorising clinicians. In this latter sense, it may be considered equivalent to a signed document.

It is strongly recommended that the inherited attribute uid be populated in Compositions, using the UID copied from the object_id() of the uid field of the enclosing VERSION object.
For example, the ORIGINAL_VERSION.uid 87284370-2D4B-4e3d-A3F3-F303D2F4F34B::uk.nhs.ehr1::2 would be copied to the uid field of the Composition.

Inherit

LOCATABLE

Attributes

Signature

Meaning

1..1

language: CODE_PHRASE

Mandatory indicator of the localised language in which this Composition is written. Coded from openEHR Code Set languages. The language of an Entry if different from the Composition is indicated in ENTRY.language.

1..1

territory: CODE_PHRASE

Name of territory in which this Composition was written. Coded from openEHR countries code set, which is an expression of the ISO 3166 standard.

1..1

category: DV_CODED_TEXT

Temporal category of this Composition, i.e.

  • 431|persistent| - of potential life-time validity;

  • 451|episodic| - valid over the life of a care episode;

  • 433|event| - valid at the time of recording (long-term validity requires subsequent clinical assessment).

or any other code defined in the openEHR terminology group 'category'.

0..1

context: EVENT_CONTEXT

The clinical session context of this Composition, i.e. the contextual attributes of the clinical session.

1..1

composer: PARTY_PROXY

The person primarily responsible for the content of the Composition (but not necessarily its committal into the EHR system). This is the identifier which should appear on the screen. It may or may not be the person who entered the data. When it is the patient, the special self instance of PARTY_PROXY will be used.

0..1

content: List<CONTENT_ITEM>

The content of this Composition.

Functions

Signature

Meaning

1..1

is_persistent (): Boolean

True if category is 431|persistent|, False otherwise. Useful for finding Compositions in an EHR which are guaranteed to be of interest to most users.

Invariants

Category_validity: terminology (Terminology_id_openehr).has_code_for_group_id (Group_id_composition_category, category.defining_code)

Is_persistent_validity: is_persistent implies context = Void

Territory_valid: code_set(Code_set_id_countries).has_code(territory)

Language_valid: code_set(Code_set_id_languages).has_code(language)

Content_valid: content /= Void implies not content.is_empty

Is_archetype_root: is_archetype_root
COMPOSITION

Content of one version in a VERSIONED_COMPOSITION. A Composition is considered the unit of modification of the record, the unit of transmission in record Extracts, and the unit of attestation by authorising clinicians. In this latter sense, it may be considered equivalent to a signed document.

It is strongly recommended that the inherited attribute uid be populated in Compositions, using the UID copied from the object_id() of the uid field of the enclosing VERSION object.
For example, the ORIGINAL_VERSION.uid 87284370-2D4B-4e3d-A3F3-F303D2F4F34B::uk.nhs.ehr1::2 would be copied to the uid field of the Composition.

Inherits: Any, PATHABLE, LOCATABLE

Attributes

LOCATABLE.name: DV_TEXT [1..1]

Runtime name of this fragment, used to build runtime paths. This is the term provided via a clinical application or batch process to name this EHR construct: its retention in the EHR faithfully preserves the original label by which this entry was known to end users.

LOCATABLE.archetype_node_id: String [1..1]

Design-time archetype identifier of this node taken from its generating archetype; used to build archetype paths. Always in the form of an at-code, e.g. at0005. This value enables a 'standardised' name for this node to be generated, by referring to the generating archetype local terminology.

At an archetype root point, the value of this attribute is always the stringified form of the archetype_id found in the archetype_details object.

LOCATABLE.uid: UID_BASED_ID [0..1]

Optional globally unique object identifier for root points of archetyped structures.

LOCATABLE.links: List<LINK> [0..1]

Links to other archetyped structures (data whose root object inherits from ARCHETYPED, such as ENTRY, SECTION and so on). Links may be to structures in other compositions.

LOCATABLE.archetype_details: ARCHETYPED [0..1]

Details of archetyping used on this node.

LOCATABLE.feeder_audit: FEEDER_AUDIT [0..1]

Audit trail from non-openEHR system of original commit of information forming the content of this node, or from a conversion gateway which has synthesised this node.

language: CODE_PHRASE [1..1]

Mandatory indicator of the localised language in which this Composition is written. Coded from openEHR Code Set languages. The language of an Entry if different from the Composition is indicated in ENTRY.language.

territory: CODE_PHRASE [1..1]

Name of territory in which this Composition was written. Coded from openEHR countries code set, which is an expression of the ISO 3166 standard.

category: DV_CODED_TEXT [1..1]

Temporal category of this Composition, i.e.

  • 431|persistent| - of potential life-time validity;

  • 451|episodic| - valid over the life of a care episode;

  • 433|event| - valid at the time of recording (long-term validity requires subsequent clinical assessment).

or any other code defined in the openEHR terminology group 'category'.

context: EVENT_CONTEXT [0..1]

The clinical session context of this Composition, i.e. the contextual attributes of the clinical session.

composer: PARTY_PROXY [1..1]

The person primarily responsible for the content of the Composition (but not necessarily its committal into the EHR system). This is the identifier which should appear on the screen. It may or may not be the person who entered the data. When it is the patient, the special self instance of PARTY_PROXY will be used.

content: List<CONTENT_ITEM> [0..1]

The content of this Composition.

Functions

(abstract) Any.is_equal (
other: Any[1]
): Boolean [1..1]

Value equality: return True if this and other are attached to objects considered to be equal in value.

Parameters
other

Other object for comparison.

Any.equal alias "=", "==" (
other: Any[1]
): Boolean [1..1]

Reference equality for reference types, value equality for value types.

Parameters
other

Other object for comparison.

Any.instance_of (
a_type: String[1]
): Any [1..1]

Create new instance of a type.

Any.type_of (
an_object: Any[1]
): String [1..1]

Type name of an object as a string. May include generic parameters, as in "Interval<Time>".

Any.not_equal alias "!=", "≠" (
other: Ordered[1]
): Boolean [1..1]

True if current object not equal to other. Returns not equal().

PATHABLE.parent (): PATHABLE [1..1]

Parent of this node in a compositional hierarchy.

PATHABLE.item_at_path (
a_path: String[1]
): Any

Pre: path_unique (a_path) [1..1]

The item at a path (relative to this item); only valid for unique paths, i.e. paths that resolve to a single item.

PATHABLE.items_at_path (
a_path: String[1]
): List<Any> [0..1]

List of items corresponding to a non-unique path.

PATHABLE.path_exists (
a_path: String[1]
): Boolean

Pre: not a_path.is_empty [1..1]

True if the path exists in the data with respect to the current item.

PATHABLE.path_unique (
a_path: String[1]
): Boolean

Pre: path_exists (a_path) [1..1]

True if the path corresponds to a single item in the data.

PATHABLE.path_of_item (
a_loc: PATHABLE[1]
): String [1..1]

The path to an item relative to the root of this archetyped structure.

LOCATABLE.concept (): DV_TEXT [1..1]

Clinical concept of the archetype as a whole (= derived from the archetype_node_id' of the root node)

LOCATABLE.is_archetype_root (): Boolean [1..1]

True if this node is the root of an archetyped structure.

is_persistent (): Boolean [1..1]

True if category is 431|persistent|, False otherwise. Useful for finding Compositions in an EHR which are guaranteed to be of interest to most users.

Invariants

LOCATABLE.Links_valid: links /= Void implies not links.is_empty

LOCATABLE.Archetyped_valid: is_archetype_root xor archetype_details = Void

LOCATABLE.Archetype_node_id_valid: not archetype_node_id.is_empty

Category_validity: terminology (Terminology_id_openehr).has_code_for_group_id (Group_id_composition_category, category.defining_code)

Is_persistent_validity: is_persistent implies context = Void

Territory_valid: code_set(Code_set_id_countries).has_code(territory)

Language_valid: code_set(Code_set_id_languages).has_code(language)

Content_valid: content /= Void implies not content.is_empty

Is_archetype_root: is_archetype_root

 
{
    "name": "COMPOSITION",
    "documentation": "Content of one version in a `VERSIONED_COMPOSITION`. A Composition is considered the unit of modification of the record, the unit of transmission in record Extracts, and the unit of attestation by authorising clinicians. In this latter sense, it may be considered equivalent to a signed document.\n\nNOTE: It is strongly recommended that the inherited attribute `_uid_` be populated in Compositions, using the UID copied from the `_object_id()_` of the `_uid_` field of the enclosing `VERSION` object. +\nFor example, the `ORIGINAL_VERSION.uid` `87284370-2D4B-4e3d-A3F3-F303D2F4F34B::uk.nhs.ehr1::2` would be copied to the `_uid_` field of the Composition.",
    "ancestors": [
        "LOCATABLE"
    ],
    "properties": {
        "language": {
            "_type": "P_BMM_SINGLE_PROPERTY",
            "name": "language",
            "documentation": "Mandatory indicator of the localised language in which this Composition is written. Coded from openEHR Code Set  `languages`. The language of an Entry if different from the Composition is indicated in `ENTRY._language_`. ",
            "is_mandatory": true,
            "type": "CODE_PHRASE"
        },
        "territory": {
            "_type": "P_BMM_SINGLE_PROPERTY",
            "name": "territory",
            "documentation": "Name of territory in which this Composition was written. Coded from openEHR  countries  code set, which is an expression of the ISO 3166 standard.",
            "is_mandatory": true,
            "type": "CODE_PHRASE"
        },
        "category": {
            "_type": "P_BMM_SINGLE_PROPERTY",
            "name": "category",
            "documentation": "Temporal category of this Composition, i.e. \n\n* `431|persistent|` - of potential life-time validity;\n* `451|episodic|` - valid over the life of a care episode;\n* `433|event|` - valid at the time of recording (long-term validity requires subsequent clinical assessment).\n\nor any other code defined in the openEHR terminology group 'category'.\n",
            "is_mandatory": true,
            "type": "DV_CODED_TEXT"
        },
        "context": {
            "_type": "P_BMM_SINGLE_PROPERTY",
            "name": "context",
            "documentation": "The clinical session context of this Composition, i.e. the contextual attributes of the clinical session. ",
            "type": "EVENT_CONTEXT"
        },
        "composer": {
            "_type": "P_BMM_SINGLE_PROPERTY",
            "name": "composer",
            "documentation": "The person primarily responsible for the content of the Composition (but not necessarily its committal into the EHR system). This is the identifier which should appear on the screen. It may or may not be the person who entered the data. When it is the patient, the special self  instance of `PARTY_PROXY` will be used.",
            "is_mandatory": true,
            "type": "PARTY_PROXY"
        },
        "content": {
            "_type": "P_BMM_CONTAINER_PROPERTY",
            "name": "content",
            "documentation": "The content of this Composition. ",
            "type_def": {
                "container_type": "List",
                "type": "CONTENT_ITEM"
            },
            "cardinality": {
                "lower": 0,
                "upper_unbounded": true
            }
        }
    },
    "functions": {
        "is_persistent": {
            "name": "is_persistent",
            "documentation": "True if category is `431|persistent|`, False otherwise. Useful for finding Compositions in an EHR which are guaranteed to be of interest to most users. ",
            "result": {
                "_type": "P_BMM_SIMPLE_TYPE",
                "type": "Boolean"
            }
        }
    },
    "invariants": {
        "Category_validity": "terminology (Terminology_id_openehr).has_code_for_group_id (Group_id_composition_category, category.defining_code)",
        "Is_persistent_validity": "is_persistent implies context = Void",
        "Territory_valid": "code_set(Code_set_id_countries).has_code(territory)",
        "Language_valid": "code_set(Code_set_id_languages).has_code(language)",
        "Content_valid": "content /= Void implies not content.is_empty",
        "Is_archetype_root": "is_archetype_root"
    }
}
COMPOSITION

EVENT_CONTEXT Class

  • Definition

  • Effective

  • BMM

  • UML

Class

EVENT_CONTEXT

Description

Documents the context information of a healthcare event involving the subject of care and the health system. The context information recorded here are independent of the attributes recorded in the version audit, which document the system interaction context, i.e. the context of a user interacting with the health record system. Healthcare events include patient contacts, and any other business activity, such as pathology investigations which take place on behalf of the patient.

Inherit

PATHABLE

Attributes

Signature

Meaning

1..1

start_time: DV_DATE_TIME

Start time of the clinical session or other kind of event during which a provider performs a service of any kind for the patient.

0..1

end_time: DV_DATE_TIME

Optional end time of the clinical session.

0..1

location: String

The actual location where the session occurred, e.g. 'microbiology lab 2', 'home', 'ward A3' and so on.

1..1

setting: DV_CODED_TEXT

The setting in which the clinical session took place. Coded using the openEHR Terminology, setting group.

0..1

other_context: ITEM_STRUCTURE

Other optional context which will be archetyped.

0..1

health_care_facility: PARTY_IDENTIFIED

The health care facility under whose care the event took place. This is the most specific workgroup or delivery unit within a care delivery enterprise that has an official identifier in the health system, and can be used to ensure medico-legal accountability.

0..1

participations: List<PARTICIPATION>

Parties involved in the healthcare event. These would normally include the physician(s) and often the patient (but not the latter if the clinical session is a pathology test for example).

Invariants

Setting_valid: Terminology (Terminology_id_openehr).has_code_for_group_id (Group_id_setting, setting.defining_code)

Participations_validity: participations /= Void implies not participations.is_empty

location_valid: location /= Void implies not location.is_empty
EVENT_CONTEXT

Documents the context information of a healthcare event involving the subject of care and the health system. The context information recorded here are independent of the attributes recorded in the version audit, which document the system interaction context, i.e. the context of a user interacting with the health record system. Healthcare events include patient contacts, and any other business activity, such as pathology investigations which take place on behalf of the patient.

Inherits: Any, PATHABLE

Attributes

start_time: DV_DATE_TIME [1..1]

Start time of the clinical session or other kind of event during which a provider performs a service of any kind for the patient.

end_time: DV_DATE_TIME [0..1]

Optional end time of the clinical session.

location: String [0..1]

The actual location where the session occurred, e.g. 'microbiology lab 2', 'home', 'ward A3' and so on.

setting: DV_CODED_TEXT [1..1]

The setting in which the clinical session took place. Coded using the openEHR Terminology, setting group.

other_context: ITEM_STRUCTURE [0..1]

Other optional context which will be archetyped.

health_care_facility: PARTY_IDENTIFIED [0..1]

The health care facility under whose care the event took place. This is the most specific workgroup or delivery unit within a care delivery enterprise that has an official identifier in the health system, and can be used to ensure medico-legal accountability.

participations: List<PARTICIPATION> [0..1]

Parties involved in the healthcare event. These would normally include the physician(s) and often the patient (but not the latter if the clinical session is a pathology test for example).

Functions

(abstract) Any.is_equal (
other: Any[1]
): Boolean [1..1]

Value equality: return True if this and other are attached to objects considered to be equal in value.

Parameters
other

Other object for comparison.

Any.equal alias "=", "==" (
other: Any[1]
): Boolean [1..1]

Reference equality for reference types, value equality for value types.

Parameters
other

Other object for comparison.

Any.instance_of (
a_type: String[1]
): Any [1..1]

Create new instance of a type.

Any.type_of (
an_object: Any[1]
): String [1..1]

Type name of an object as a string. May include generic parameters, as in "Interval<Time>".

Any.not_equal alias "!=", "≠" (
other: Ordered[1]
): Boolean [1..1]

True if current object not equal to other. Returns not equal().

PATHABLE.parent (): PATHABLE [1..1]

Parent of this node in a compositional hierarchy.

PATHABLE.item_at_path (
a_path: String[1]
): Any

Pre: path_unique (a_path) [1..1]

The item at a path (relative to this item); only valid for unique paths, i.e. paths that resolve to a single item.

PATHABLE.items_at_path (
a_path: String[1]
): List<Any> [0..1]

List of items corresponding to a non-unique path.

PATHABLE.path_exists (
a_path: String[1]
): Boolean

Pre: not a_path.is_empty [1..1]

True if the path exists in the data with respect to the current item.

PATHABLE.path_unique (
a_path: String[1]
): Boolean

Pre: path_exists (a_path) [1..1]

True if the path corresponds to a single item in the data.

PATHABLE.path_of_item (
a_loc: PATHABLE[1]
): String [1..1]

The path to an item relative to the root of this archetyped structure.

Invariants

Setting_valid: Terminology (Terminology_id_openehr).has_code_for_group_id (Group_id_setting, setting.defining_code)

Participations_validity: participations /= Void implies not participations.is_empty

location_valid: location /= Void implies not location.is_empty

 
{
    "name": "EVENT_CONTEXT",
    "documentation": "Documents the context information of a healthcare event involving the subject of care and the health system. The context information recorded here are independent of the attributes recorded in the version audit, which document the  system interaction  context, i.e. the context of a user interacting with the health record system. Healthcare events include patient contacts, and any other business activity, such as pathology investigations which take place on behalf of the patient. ",
    "ancestors": [
        "PATHABLE"
    ],
    "properties": {
        "start_time": {
            "_type": "P_BMM_SINGLE_PROPERTY",
            "name": "start_time",
            "documentation": "Start time of the clinical session or other kind of event during which a provider performs a service of any kind for the patient. ",
            "is_mandatory": true,
            "type": "DV_DATE_TIME"
        },
        "end_time": {
            "_type": "P_BMM_SINGLE_PROPERTY",
            "name": "end_time",
            "documentation": "Optional end time of the clinical session. \n",
            "type": "DV_DATE_TIME"
        },
        "location": {
            "_type": "P_BMM_SINGLE_PROPERTY",
            "name": "location",
            "documentation": "The actual location where the session occurred, e.g. 'microbiology lab 2', 'home', 'ward A3'  and so on.",
            "type": "String"
        },
        "setting": {
            "_type": "P_BMM_SINGLE_PROPERTY",
            "name": "setting",
            "documentation": "The setting in which the clinical session took place. Coded using the openEHR Terminology,  setting  group. ",
            "is_mandatory": true,
            "type": "DV_CODED_TEXT"
        },
        "other_context": {
            "_type": "P_BMM_SINGLE_PROPERTY",
            "name": "other_context",
            "documentation": "Other optional context which will be archetyped.",
            "type": "ITEM_STRUCTURE"
        },
        "health_care_facility": {
            "_type": "P_BMM_SINGLE_PROPERTY",
            "name": "health_care_facility",
            "documentation": "The health care facility under whose care the event took place. This is the most specific workgroup or delivery unit within a care delivery enterprise that has an official identifier in the health system, and can be used to ensure medico-legal accountability. ",
            "type": "PARTY_IDENTIFIED"
        },
        "participations": {
            "_type": "P_BMM_CONTAINER_PROPERTY",
            "name": "participations",
            "documentation": "Parties involved in the healthcare event. These would normally include the physician(s) and often the patient (but not the latter if the clinical session is a pathology test for example). ",
            "type_def": {
                "container_type": "List",
                "type": "PARTICIPATION"
            },
            "cardinality": {
                "lower": 0,
                "upper_unbounded": true
            }
        }
    },
    "invariants": {
        "Setting_valid": "Terminology (Terminology_id_openehr).has_code_for_group_id (Group_id_setting, setting.defining_code)",
        "Participations_validity": "participations /= Void implies not participations.is_empty",
        "location_valid": "location /= Void implies not location.is_empty"
    }
}
EVENT_CONTEXT