Generic Package
Overview
The classes presented in this section are abstractions of concepts which are generic patterns in the domain of health (and most likely other domains), such as 'participation' and 'attestation'. The generic cluster is shown below.
Design Principles
Referring to Demographic Entities
There are two ways to refer to a demographic identity in the openEHR EHR: using PARTY_REF directly, which records an identifier of the party in some external system, and using PARTY_PROXY, consisting of a small amount of descriptive data, depending on the subtype, and an optional PARTY_REF. The semantics of PARTY_REF are described in the Base Types identification package, while the semantics of PARTY_PROXY and use of PARTY_REF in such entities are described below. The approach taken in openEHR for representing demographic and user entities in the EHR data isbased on the following assumptions:
-
there is at least one human readable name or official identifier of the party, such as
"Julius Marlowe, MD","NHS provider number 1039385", or a system user id such as"Rahil.Azam"; -
there might be data in a service external to the EHR for the party in question, such as a demographic, identity management or patient index service; if there is, it should be referenceable;
-
the subject of the record is never to be identified in any direct way (i.e. via the use of her name or other human-readable details), but may include a meaningless identifier in some external system.
The PARTY_PROXY class and subtypes model references to parties based on these assumptions. The semantics of PARTY_PROXY enable a flexible approach: in stricter environments that have identity management and demographic services, and where there is an entry in such a service for the party in question, PARTY_PROXY.external_ref will be non-Void, while in other environments, it will be empty.
The two subtypes correspond to the mutually distinct categories of the 'subject of the record', known as the 'self' party in openEHR, and any other party. Whenever the record subject has to be referred to in the record, an instance of PARTY_SELF is used, while PARTY_IDENTIFIED is used for all other situations. The latter class provides for optional human-readable names and formal identifiers, each keyed by purpose or meaning.
The PARTY_RELATED type is used whenever the relationship of the party to the record subject is required. Relationships are coded and include familial ones ('mother', 'uncle', etc) as well as relationships like 'donor', 'travelling companion' and so on.
PARTY_SELF and Referring to the Patient from the EHR
There are three schemes which are likely to be used for referring to patient (i.e. the record subject) demographic or patient master index (PMI) data from within the EHR, each likely to be valid in different circumstances. Each uses a PARTY_SELF object but with varying usage of the external_ref attribute, and are as follows.
-
The
external_refattribute is not set on any instances ofPARTY_SELF, i.e. nowhere in the EHR. This is the most secure approach, and means that the link between the EHR and the patient has to be done outside the EHR, by associatingEHR.ehr_idand the patient demographic/ PMI identifier. This approach is more likely in more open data sharing environments. -
The
external_refattribute is set once only inEHR_STATUS.subject. Since theEHR_STATUSobject is separate from the EHR contents, the root instance ofPARTY_SELFwill generally not be visible. -
Setting the external_ref in every instance of
PARTY_SELF; this solution makes the patient external_ref visible in every instance ofPARTY_SELF, which is reasonable in a secure environment, and convenient for copying parts of the record around locally.
All three schemes are supported by the openEHR model, and will probably all find use in different settings and EHR deployment types.
Participation
The Participation abstraction models the interaction of some Party in an activity. In the openEHR reference models, participations are actually modelled in two ways. In situations where the kinds of participation are known and constant, they are modelled as a named attribute in the relevant reference model. For example, the committer: PARTY_PROXY attribute in AUDIT_DETAILS models a participation in which the function is "committal". Where the kind of participation is not known at design time, a descendant of the generic PARTICIPATION class is used.
Audit Information
Audit Details
Three classes are provided to represent audit information. The first, AUDIT_DETAILS expresses the details that would be captured about a user when committing some information to a repository of some kind, which may be version controlled. It records the system_id_, committer, time_committed, change_type and an optoinal description.
The system_id attribute is used to record the identifier of the logical EHR repository to which the data containing the audit are committed. What constitutes a 'system' in this context is described in more detail in the Architecture Overview.
Committer is recorded using a PARTY_PROXY, allowing for PARTY_SELF to be used when the committer is the record subject, and for other identifying information to be included for other users, expressed using PARTY_IDENTIFIED. The kind of identifying information used in PARTY_PROXY instances in AUDIT_DETAILS may be different from that used in COMPOSITION.composer or elsewhere, i.e. in the form of a system login identifier, e.g. "maxime.lavache@stpatricks.health.ie".
Revision History
The classes REVISION_HISTORY and REVISION_HISTORY_ITEM express the notion of a revision history, which consists of audit items, each associated with a revision number. An instance of the REVISION_HISTORY_ITEM class is designed to express the information that corresponds to an item in a revision history, i.e. a list of all audits relating to some information item. The version_id is included to indicate which revision each audit corresponds to. These classes provide an interoperable definition of revision history for the VERSIONED_OBJECT and AUTHORED_RESOURCE classes.
Attestation
Attestation is another concept which occurs commonly in health information. An attestation is an explicit signing by one healthcare agent of particular content for various particular purposes, including:
-
for authorisation of a controlled substance or procedure (e.g. sectioning of patient under mental health act);
-
witnessing of content by senior clinical professional;
-
indicating acknowledgement of content by intended recipient, e.g. GP who ordered a test result.
Here it is modelled as a subtype of AUDIT_DETAILS, meaning that it is logically a kind of audit, with additional information pertinant to the act of signing. The contents of an ATTESTATION are as follows:
-
the identity of the attesting party (
AUDIT_DETAILS.committer); -
the date and time of the action of attestation (
AUDIT_DETAILS.time_committed); -
references to items in the record being attested to (
ATTESTATION.items); if this list is empty, the attestation is for the entire object (usually the content of anORIGINAL_VERSION) to which the attestation is attached, otherwise the list must contain a set of paths to items within the item to which the attestation is attached; -
an optionally coded reason for attestation (
ATTESTATION.reason); -
an optional literal view of the content attested, e.g. a binary screen image;
-
a proof of attestation in the form of a digital signature by the attesting party.
The digital signature, if present, is generated using the openPGP standard (IETF RFC 4880) as, according to the process shown below.
In this process, the attestation object is serialised into a canonical text form, and then hashed to create a digest. A digital signature is created from the hash, using the user’s private key. The result is then radix-64 encoded to create an ASCII string so as to remove or reduce potential problems with subsequent communication. The openPGP standard ensures that the transformations and algorithms used to create the signature are indicated within it (i.e. the signature is self-describing).
The serialisation process works by the simple rule of serialising the entire Attestation object (note that the proof attribute will be Void at this point) into an agreed XML, openEHR ODIN or other text format, then applying the subsequent transformations to the serialised data, then writing the digest result back into the proof attribute.
To Be Determined: The exact serialisation is not yet defined by openEHR, but dADL might be preferred since it has an unambiguous encoding of object structures, whereas XML libraries generate different XML from the same objects.
Normally the list of items being attested should be a single Entry or Composition, but there is nothing stopping it including fine-grained items, even though separate attestation of such items does not appear to be commensurate with good clinical information design or process.
The reason attribute is used to indicate why the attestation occurred, and is coded using the openEHR Terminology group "attestation reason", which includes values such as "authorisation" and "witnessed". The is_pending attribute marks the attestation as either having been done or awaiting completion depending on its value. This facilitates querying the record to find items needing to be signed or witnessed. When an attestation is required, the most common scenario will be that a Composition Version will be committed with a commit_audit of type ATTESTATION, rather than just AUDIT_DETAILS; the is_pending flag will be set to True to indicate that the committed information needs to be signed by another person. When signing occurs, it will cause a new ATTESTATION object to be added to the VERSION.attestations list, this time with is_pending set to False, and the appropriate proof supplied. Thus, the common situation in which content is committed to the record and needs later review and signing by a senior person will cause the creation of two ATTESTATION objects.
Class Descriptions
PARTY_PROXY Class
-
Definition
-
Effective
-
BMM
-
UML
Class |
PARTY_PROXY (abstract) |
|
|---|---|---|
Description |
Abstract concept of a proxy description of a party, including an optional link to data for this party in a demographic or other identity management system. Sub- typed into |
|
Attributes |
Signature |
Meaning |
0..1 |
external_ref: |
Optional reference to more detailed demographic or identification information for this party, in an external system. |
| PARTY_PROXY (abstract) | |
|---|---|
Abstract concept of a proxy description of a party, including an optional link to data for this party in a demographic or other identity management system. Sub- typed into |
|
Attributes |
|
external_ref: |
Optional reference to more detailed demographic or identification information for this party, in an external system. |
{
"name": "PARTY_PROXY",
"documentation": "Abstract concept of a proxy description of a party, including an optional link to data for this party in a demographic or other identity management system. Sub- typed into `PARTY_IDENTIFIED` and `PARTY_SELF`. ",
"is_abstract": true,
"properties": {
"external_ref": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "external_ref",
"documentation": "Optional reference to more detailed demographic or identification information for this party, in an external system. ",
"type": "PARTY_REF"
}
}
}PARTY_SELF Class
-
Definition
-
Effective
-
BMM
-
UML
Class |
PARTY_SELF |
|
|---|---|---|
Description |
Party proxy representing the subject of the record. Used to indicate that the party is the owner of the record. May or may not have |
|
Inherit |
||
| PARTY_SELF | |
|---|---|
Party proxy representing the subject of the record. Used to indicate that the party is the owner of the record. May or may not have |
|
Inherits: PARTY_PROXY |
|
Attributes |
|
PARTY_PROXY.external_ref: |
Optional reference to more detailed demographic or identification information for this party, in an external system. |
{
"name": "PARTY_SELF",
"documentation": "Party proxy representing the subject of the record. Used to indicate that the party is the owner of the record. May or may not have `_external_ref_` set. ",
"ancestors": [
"PARTY_PROXY"
]
}PARTY_IDENTIFIED Class
-
Definition
-
Effective
-
BMM
-
UML
Class |
PARTY_IDENTIFIED |
|
|---|---|---|
Description |
Proxy data for an identified party other than the subject of the record, minimally consisting of human-readable identifier(s), such as name, formal (and possibly computable) identifiers such as NHS number, and an optional link to external data. There must be at least one of name, identifier or external_ref present. Used to describe parties where only identifiers may be known, and there is no entry at all in the demographic system (or even no demographic system). Typically for health care providers, e.g. name and provider number of an institution. Should not be used to include patient identifying information. |
|
Inherit |
||
Attributes |
Signature |
Meaning |
0..1 |
name: |
Optional human-readable name (in String form). |
0..1 |
identifiers: |
One or more formal identifiers (possibly computable). |
Invariants |
Basic_validity: |
|
Name_valid: |
||
Identifiers_valid: |
||
| PARTY_IDENTIFIED | |
|---|---|
Proxy data for an identified party other than the subject of the record, minimally consisting of human-readable identifier(s), such as name, formal (and possibly computable) identifiers such as NHS number, and an optional link to external data. There must be at least one of name, identifier or external_ref present. Used to describe parties where only identifiers may be known, and there is no entry at all in the demographic system (or even no demographic system). Typically for health care providers, e.g. name and provider number of an institution. Should not be used to include patient identifying information. |
|
Inherits: PARTY_PROXY |
|
Attributes |
|
PARTY_PROXY.external_ref: |
Optional reference to more detailed demographic or identification information for this party, in an external system. |
name: |
Optional human-readable name (in String form). |
identifiers: |
One or more formal identifiers (possibly computable). |
Invariants |
|
Basic_validity: |
|
Name_valid: |
|
Identifiers_valid: |
|
{
"name": "PARTY_IDENTIFIED",
"documentation": "Proxy data for an identified party other than the subject of the record, minimally consisting of human-readable identifier(s), such as name, formal (and possibly computable) identifiers such as NHS number, and an optional link to external data. There must be at least one of name, identifier or external_ref present.\n\nUsed to describe parties where only identifiers may be known, and there is no entry at all in the demographic system (or even no demographic system). Typically for health care providers, e.g. name and provider number of an institution. \n\nShould not be used to include patient identifying information. ",
"ancestors": [
"PARTY_PROXY"
],
"properties": {
"name": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "name",
"documentation": "Optional human-readable name (in String form).",
"type": "String"
},
"identifiers": {
"_type": "P_BMM_CONTAINER_PROPERTY",
"name": "identifiers",
"documentation": "One or more formal identifiers (possibly computable). \n",
"type_def": {
"container_type": "List",
"type": "DV_IDENTIFIER"
},
"cardinality": {
"lower": 0,
"upper_unbounded": true
}
}
},
"invariants": {
"Basic_validity": "name /= Void or identifiers /= Void or external_ref /= Void",
"Name_valid": "name /= Void implies not name.is_empty",
"Identifiers_valid": "identifiers /= Void implies not identifiers.is_empty"
}
}PARTY_RELATED Class
-
Definition
-
Effective
-
BMM
-
UML
Class |
PARTY_RELATED |
|
|---|---|---|
Description |
Proxy type for identifying a party and its relationship to the subject of the record. Use where the relationship between the party and the subject of the record must be known. |
|
Inherit |
||
Attributes |
Signature |
Meaning |
1..1 |
relationship: |
Relationship of subject of this ENTRY to the subject of the record. May be coded. If it is the patient, coded as self. |
Invariants |
Relationship_valid: |
|
| PARTY_RELATED | |
|---|---|
Proxy type for identifying a party and its relationship to the subject of the record. Use where the relationship between the party and the subject of the record must be known. |
|
Inherits: PARTY_PROXY, PARTY_IDENTIFIED |
|
Attributes |
|
PARTY_PROXY.external_ref: |
Optional reference to more detailed demographic or identification information for this party, in an external system. |
PARTY_IDENTIFIED.name: |
Optional human-readable name (in String form). |
PARTY_IDENTIFIED.identifiers: |
One or more formal identifiers (possibly computable). |
relationship: |
Relationship of subject of this ENTRY to the subject of the record. May be coded. If it is the patient, coded as self. |
Invariants |
|
PARTY_IDENTIFIED.Basic_validity: |
|
PARTY_IDENTIFIED.Name_valid: |
|
PARTY_IDENTIFIED.Identifiers_valid: |
|
Relationship_valid: |
|
{
"name": "PARTY_RELATED",
"documentation": "Proxy type for identifying a party and its relationship to the subject of the record. Use where the relationship between the party and the subject of the record must be known. ",
"ancestors": [
"PARTY_IDENTIFIED"
],
"properties": {
"relationship": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "relationship",
"documentation": "Relationship of subject of this ENTRY to the subject of the record. May be coded. If it is the patient, coded as self. ",
"is_mandatory": true,
"type": "DV_CODED_TEXT"
}
},
"invariants": {
"Relationship_valid": "terminology (Terminology_id_openehr).has_code_for_group_id (Group_id_subject_relationship, relationship.defining_code)"
}
}PARTICIPATION Class
-
Definition
-
Effective
-
BMM
-
UML
Class |
PARTICIPATION |
|
|---|---|---|
Description |
Model of a participation of a Party (any Actor or Role) in an activity. Used to represent any participation of a Party in some activity, which is not explicitly in the model, e.g. assisting nurse. Can be used to record past or future participations. Should not be used in place of more permanent relationships between demographic entities. |
|
Attributes |
Signature |
Meaning |
1..1 |
function: |
The function of the Party in this participation (note that a given party might participate in more than one way in a particular activity). This attribute should be coded, but cannot be limited to the HL7v3:ParticipationFunction vocabulary, since it is too limited and hospital-oriented. |
0..1 |
mode: |
Optional field for recording the 'mode' of the performer / activity interaction, e.g. present, by telephone, by email etc. |
1..1 |
performer: |
The id and possibly demographic system link of the party participating in the activity. |
0..1 |
time: |
The time interval during which the participation took place, if it is used in an observational context (i.e. recording facts about the past); or the intended time interval of the participation when used in future contexts, such as EHR Instructions. |
Invariants |
Function_valid: |
|
Mode_valid: |
||
| PARTICIPATION | |
|---|---|
Model of a participation of a Party (any Actor or Role) in an activity. Used to represent any participation of a Party in some activity, which is not explicitly in the model, e.g. assisting nurse. Can be used to record past or future participations. Should not be used in place of more permanent relationships between demographic entities. |
|
Attributes |
|
function: |
The function of the Party in this participation (note that a given party might participate in more than one way in a particular activity). This attribute should be coded, but cannot be limited to the HL7v3:ParticipationFunction vocabulary, since it is too limited and hospital-oriented. |
mode: |
Optional field for recording the 'mode' of the performer / activity interaction, e.g. present, by telephone, by email etc. |
performer: |
The id and possibly demographic system link of the party participating in the activity. |
time: |
The time interval during which the participation took place, if it is used in an observational context (i.e. recording facts about the past); or the intended time interval of the participation when used in future contexts, such as EHR Instructions. |
Invariants |
|
Function_valid: |
|
Mode_valid: |
|
{
"name": "PARTICIPATION",
"documentation": "Model of a participation of a Party (any Actor or Role) in an activity. Used to represent any participation of a Party in some activity, which is not explicitly in the model, e.g. assisting nurse. Can be used to record past or future participations. \n\nShould not be used in place of more permanent relationships between demographic entities. ",
"properties": {
"function": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "function",
"documentation": "The function of the Party in this participation (note that a given party might participate in more than one way in a particular activity). This attribute should be coded, but cannot be limited to the HL7v3:ParticipationFunction vocabulary, since it is too limited and hospital-oriented. ",
"is_mandatory": true,
"type": "DV_TEXT"
},
"mode": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "mode",
"documentation": "Optional field for recording the 'mode' of the performer / activity interaction, e.g. present, by telephone, by email etc. ",
"type": "DV_CODED_TEXT"
},
"performer": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "performer",
"documentation": "The id and possibly demographic system link of the party participating in the activity. ",
"is_mandatory": true,
"type": "PARTY_PROXY"
},
"time": {
"_type": "P_BMM_GENERIC_PROPERTY",
"name": "time",
"documentation": "The time interval during which the participation took place, if it is used in an observational context (i.e. recording facts about the past); or the intended time interval of the participation when used in future contexts, such as EHR Instructions. ",
"type_def": {
"root_type": "DV_INTERVAL",
"generic_parameters": [
"DV_DATE_TIME"
]
}
}
},
"invariants": {
"Function_valid": "function.generating_type.is_equal (\"DV_CODED_TEXT\") implies\nterminology (Terminology_id_openehr).has_code_for_group_id (Group_id_participation_function, function.defining_code)",
"Mode_valid": "mode /= Void implies terminology (Terminology_id_openehr).has_code_for_group_id (Group_id_participation_mode, mode.defining_code)"
}
}AUDIT_DETAILS Class
-
Definition
-
Effective
-
BMM
-
UML
Class |
AUDIT_DETAILS |
|
|---|---|---|
Description |
The set of attributes required to document the committal of an information item to a repository. |
|
Attributes |
Signature |
Meaning |
1..1 |
system_id: |
Identifier of the logical EHR system where the change was committed. This is almost always owned by the organisation legally responsible for the EHR, and is distinct from any application, or any hosting infrastructure. |
1..1 |
time_committed: |
Time of committal of the item. |
1..1 |
change_type: |
Type of change. Coded using the openEHR Terminology audit change type group. |
0..1 |
description: |
Reason for committal. This may be used to qualify the value in the |
1..1 |
committer: |
Identity and optional reference into identity management service, of user who committed the item. |
Invariants |
System_id_valid: |
|
Change_type_valid: |
||
| AUDIT_DETAILS | |
|---|---|
The set of attributes required to document the committal of an information item to a repository. |
|
Attributes |
|
system_id: |
Identifier of the logical EHR system where the change was committed. This is almost always owned by the organisation legally responsible for the EHR, and is distinct from any application, or any hosting infrastructure. |
time_committed: |
Time of committal of the item. |
change_type: |
Type of change. Coded using the openEHR Terminology audit change type group. |
description: |
Reason for committal. This may be used to qualify the value in the |
committer: |
Identity and optional reference into identity management service, of user who committed the item. |
Invariants |
|
System_id_valid: |
|
Change_type_valid: |
|
{
"name": "AUDIT_DETAILS",
"documentation": "The set of attributes required to document the committal of an information item to a repository. ",
"properties": {
"system_id": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "system_id",
"documentation": "Identifier of the logical EHR system where the change was committed. This is almost always owned by the organisation legally responsible for the EHR, and is distinct from any application, or any hosting infrastructure.",
"is_mandatory": true,
"type": "String"
},
"time_committed": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "time_committed",
"documentation": "Time of committal of the item. ",
"is_mandatory": true,
"type": "DV_DATE_TIME"
},
"change_type": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "change_type",
"documentation": "Type of change. Coded using the openEHR Terminology audit change type group.",
"is_mandatory": true,
"type": "DV_CODED_TEXT"
},
"description": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "description",
"documentation": "Reason for committal. This may be used to qualify the value in the `_change_type_` field. For example, if the change affects only the EHR directory, this field might be used to indicate 'Folder \"episode 2018-02-16\" added' or similar.",
"type": "DV_TEXT"
},
"committer": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "committer",
"documentation": "Identity and optional reference into identity management service, of user who committed the item. ",
"is_mandatory": true,
"type": "PARTY_PROXY"
}
},
"invariants": {
"System_id_valid": "not system_id.is_empty",
"Change_type_valid": "terminology (Terminology_id_openehr).has_code_for_group_id (Group_id_audit_change_type, change_type.defining_code)"
}
}ATTESTATION Class
-
Definition
-
Effective
-
BMM
-
UML
Class |
ATTESTATION |
|
|---|---|---|
Description |
Record an attestation of a party (the committer) to item(s) of record content. An attestation is an explicit signing by one healthcare agent of particular content for various particular purposes, including:
|
|
Inherit |
||
Attributes |
Signature |
Meaning |
0..1 |
attested_view: |
Optional visual representation of content attested e.g. screen image. |
0..1 |
proof: |
Proof of attestation. |
0..1 |
items: |
Items attested, expressed as fully qualified runtime paths to the items in question. Although not recommended, these may include fine-grained items which have been attested in some other system. Otherwise it is assumed to be for the entire VERSION with which it is associated. |
1..1 |
reason: |
Reason of this attestation. Optionally coded by the openEHR Terminology group attestation reason ; includes values like authorisation , witness etc. |
1..1 |
is_pending: |
True if this attestation is outstanding; False means it has been completed. |
Invariants |
Items_valid: |
|
Reason_valid: |
||
| ATTESTATION | |
|---|---|
Record an attestation of a party (the committer) to item(s) of record content. An attestation is an explicit signing by one healthcare agent of particular content for various particular purposes, including:
|
|
Inherits: AUDIT_DETAILS |
|
Attributes |
|
AUDIT_DETAILS.system_id: |
Identifier of the logical EHR system where the change was committed. This is almost always owned by the organisation legally responsible for the EHR, and is distinct from any application, or any hosting infrastructure. |
AUDIT_DETAILS.time_committed: |
Time of committal of the item. |
AUDIT_DETAILS.change_type: |
Type of change. Coded using the openEHR Terminology audit change type group. |
AUDIT_DETAILS.description: |
Reason for committal. This may be used to qualify the value in the |
AUDIT_DETAILS.committer: |
Identity and optional reference into identity management service, of user who committed the item. |
attested_view: |
Optional visual representation of content attested e.g. screen image. |
proof: |
Proof of attestation. |
items: |
Items attested, expressed as fully qualified runtime paths to the items in question. Although not recommended, these may include fine-grained items which have been attested in some other system. Otherwise it is assumed to be for the entire VERSION with which it is associated. |
reason: |
Reason of this attestation. Optionally coded by the openEHR Terminology group attestation reason ; includes values like authorisation , witness etc. |
is_pending: |
True if this attestation is outstanding; False means it has been completed. |
Invariants |
|
AUDIT_DETAILS.System_id_valid: |
|
AUDIT_DETAILS.Change_type_valid: |
|
Items_valid: |
|
Reason_valid: |
|
{
"name": "ATTESTATION",
"documentation": "Record an attestation of a party (the committer) to item(s) of record content. An attestation is an explicit signing by one healthcare agent of particular content for various particular purposes, including:\n\n* for authorisation of a controlled substance or procedure (e.g. sectioning of patient under mental health act); \n* witnessing of content by senior clinical professional; \n* indicating acknowledgement of content by intended recipient, e.g. GP who ordered a test result. \n",
"ancestors": [
"AUDIT_DETAILS"
],
"properties": {
"attested_view": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "attested_view",
"documentation": "Optional visual representation of content attested e.g. screen image. ",
"type": "DV_MULTIMEDIA"
},
"proof": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "proof",
"documentation": "Proof of attestation. ",
"type": "String"
},
"items": {
"_type": "P_BMM_CONTAINER_PROPERTY",
"name": "items",
"documentation": "Items attested, expressed as fully qualified runtime paths to the items in question. Although not recommended, these may include fine-grained items which have been attested in some other system. Otherwise it is assumed to be for the entire VERSION with which it is associated. ",
"type_def": {
"container_type": "List",
"type": "DV_EHR_URI"
},
"cardinality": {
"lower": 0,
"upper_unbounded": true
}
},
"reason": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "reason",
"documentation": "Reason of this attestation. Optionally coded by the openEHR Terminology group attestation reason ; includes values like authorisation , witness etc. ",
"is_mandatory": true,
"type": "DV_TEXT"
},
"is_pending": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "is_pending",
"documentation": "True if this attestation is outstanding; False means it has been completed.",
"is_mandatory": true,
"type": "Boolean"
}
},
"invariants": {
"Items_valid": "items /= Void implies not items.is_empty",
"Reason_valid": "(reason.generating_type.is_equal (“DV_CODED_TEXT”) implies terminology (Terminology_id_openehr).has_code_for_group_id (Group_id_attestation_reason, reason.defining_code))"
}
}REVISION_HISTORY Class
-
Definition
-
Effective
-
BMM
-
UML
Class |
REVISION_HISTORY |
|
|---|---|---|
Description |
Purpose Defines the notion of a revision history of audit items, each associated with the version for which that audit was committed. The list is in most-recent-first order. |
|
Attributes |
Signature |
Meaning |
1..1 |
items: |
The items in this history in most-recent-last order. |
Functions |
Signature |
Meaning |
1..1 |
most_recent_version (): |
The version id of the most recent item, as a String. |
1..1 |
most_recent_version_time_committed (): |
The commit date/time of the most recent item, as a String. |
| REVISION_HISTORY | |
|---|---|
Purpose Defines the notion of a revision history of audit items, each associated with the version for which that audit was committed. The list is in most-recent-first order. |
|
Attributes |
|
items: |
The items in this history in most-recent-last order. |
Functions |
|
most_recent_version (): |
The version id of the most recent item, as a String. |
most_recent_version_time_committed (): |
The commit date/time of the most recent item, as a String. |
{
"name": "REVISION_HISTORY",
"documentation": "Purpose Defines the notion of a revision history of audit items, each associated with the version for which that audit was committed. The list is in most-recent-first order. ",
"properties": {
"items": {
"_type": "P_BMM_CONTAINER_PROPERTY",
"name": "items",
"documentation": "The items in this history in most-recent-last order. ",
"is_mandatory": true,
"type_def": {
"container_type": "List",
"type": "REVISION_HISTORY_ITEM"
},
"cardinality": {
"lower": 1,
"upper_unbounded": true
}
}
},
"functions": {
"most_recent_version": {
"name": "most_recent_version",
"documentation": "The version id of the most recent item, as a String.",
"post_conditions": {
"Post": "Result.is_equal (items.last.version_id.value)"
},
"result": {
"_type": "P_BMM_SIMPLE_TYPE",
"type": "String"
}
},
"most_recent_version_time_committed": {
"name": "most_recent_version_time_committed",
"documentation": "The commit date/time of the most recent item, as a String. ",
"post_conditions": {
"Post": "Result.is_equal (items.last.audits.first. time_committed.value)"
},
"result": {
"_type": "P_BMM_SIMPLE_TYPE",
"type": "String"
}
}
}
}REVISION_HISTORY_ITEM Class
-
Definition
-
Effective
-
BMM
-
UML
Class |
REVISION_HISTORY_ITEM |
|
|---|---|---|
Description |
An entry in a revision history, corresponding to a version from a versioned container. Consists of |
|
Attributes |
Signature |
Meaning |
1..1 |
version_id: |
Version identifier for this revision. |
1..1 |
audits: |
The audits for this revision; there will always be at least one commit audit (which may itself be an |
Invariants |
Audit_valid: |
|
| REVISION_HISTORY_ITEM | |
|---|---|
An entry in a revision history, corresponding to a version from a versioned container. Consists of |
|
Attributes |
|
version_id: |
Version identifier for this revision. |
audits: |
The audits for this revision; there will always be at least one commit audit (which may itself be an |
Invariants |
|
Audit_valid: |
|
{
"name": "REVISION_HISTORY_ITEM",
"documentation": "An entry in a revision history, corresponding to a version from a versioned container. Consists of `AUDIT_DETAILS` instances with revision identifier of the revision to which the `AUDIT_DETAILS` instance belongs. ",
"properties": {
"version_id": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "version_id",
"documentation": "Version identifier for this revision. ",
"is_mandatory": true,
"type": "OBJECT_VERSION_ID"
},
"audits": {
"_type": "P_BMM_CONTAINER_PROPERTY",
"name": "audits",
"documentation": "The audits for this revision; there will always be at least one commit audit (which may itself be an `ATTESTATION`), there may also be further attestations. ",
"is_mandatory": true,
"type_def": {
"container_type": "List",
"type": "AUDIT_DETAILS"
},
"cardinality": {
"lower": 1,
"upper_unbounded": true
}
}
},
"invariants": {
"Audit_valid": "not audits.is_empty"
}
}