openEHR Simplified Information Model 'B'
Issuer: openEHR Specification Program | |
---|---|
Release: SM development |
Status: DEVELOPMENT |
Revision: [latest_issue] |
Date: [latest_issue_date] |
Keywords: SIM-B, information model, openEHR |
© 2019 - 2024 The openEHR Foundation | |
---|---|
The openEHR Foundation is an independent, non-profit foundation, facilitating the sharing of health records by consumers and clinicians via open specifications, clinical models and open platform implementations. |
|
Licence |
Creative Commons Attribution-NoDerivs 3.0 Unported. https://creativecommons.org/licenses/by-nd/3.0/ |
Support |
Issues: Problem Reports |
Acknowledgements
Contributors
This specification has benefited from 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.
-
xxxx
1. Preface
1.1. Purpose
This document describes the Simplified Information Model 'B' (SIM-B) format, a simplified form of the openEHR RM, intended to be used to generate the simplified JSON Data Template (sJDT) format. The SIM-B model is designed to enable easier creation of openEHR content (i.e. Compositions etc).
1.2. Status
This specification is in the DEVELOPMENT state. The development version of this document can be found at https://specifications.openehr.org/releases/SM/development/simplified_im_b.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.3. Feedback
Feedback may be provided on the technical mailing list.
Issues may be raised on the specifications Problem Report tracker.
To see changes made due to previously reported issues, see the SM component Change Request tracker.
2. Overview
The Simplified Information Model (SIM) is a version of the canonical Reference Model and Base Model (RM, BASE components respectively) that contains structurally simpler representations of many class attributes, enabling easier construction of string-oriented serialisations such as JSON, compared to the full canonical structures. The SIM is defined as a set of classes named after a sub-set of RM classes, with S_
prepended; for example, in the SIM, the RM class ELEMENT
becomes S_ELEMENT
.
Various kinds of simpilifications are used in the SIM classes, including:
-
String representation of some fields that are structured in the RM, e.g
CODE_PHRASE.terminology_id
is of typeTERMINOLOGY_ID
but in the SIM, it is aString
; -
replacing fully expressed
DV_CODED_TEXT
orCODE_PHRASE
fields that represent codes from openEHR or other fixed (e.g. IANA media type) vocabularies which are determinable from the openEHR RM, with Strings; -
compressing fields of some sub-part objects into a parent object in the simplified version, reducing the need for long paths, e.g.
S_PARTY_PROXY
includes fields fromPARTY_PROXY.external_ref
, of typePARTY_REF
.
The cost of doing the above is that some work has to be done to convert an S_XXX
instance into an XXX
canonical instance, in some cases, requiring the use of a formal representation of the RM. In openEHR, this is available in the form of a BMM model, as described in the openEHR Basic-Meta Model specification. Additionally, some fields in data have to be parsed with various micro-parsers, e.g. for Date/Time.
The subset of RM classes for which SIM classes are defined is limited to the class COMPOSITION
and classes reachable from it, or approximately 45 classes. Almost all simplifications are defined in near-leaf classes such as the S_DATA_VALUE
descendants, PARTICIPATION
and so on; classes such as S_ENTRY
and S_COMPOSITION
are largely structured the same way as in the canonical RM, except that sub-parts are of type S_XXX
rather than XXX
, where the latter is an original RM type. The exception to this is replacement of coded fields whose vocabulary is defined in the RM.
TODO: describe transformation rules representation. This could be formalised into the BMM as a new kind of structure, which would allow formal representation in BMM of transformation rules. At the moment, a few example rules are shown below interspersed within class definitions. In the final form, these rules would be removed to a separate section / source file in either BMM, or some formal language.
The specific transformations between SIM and RM instances are expressed in the tables in the Transformation Rules sub-sections below.
2.1. Simplified IM Package
TODO: we may remove the to_rm()
/ from_from()
approach and just stick with rules.
The following UML diagram shows the top-level simplified_im_b
package defining the special interface type S_TYPE
.
sm.simplified_im_b
package2.1.1. Class Definitions
2.1.1.1. S_TYPE Class
Class |
S_TYPE (abstract) |
|||
---|---|---|---|---|
Description |
Interface defining routine signatures for Simplified RM classes defining how to convert to and from the corresponding RM class. Specialised in descendants. |
|||
Functions |
Signature |
Meaning |
||
1..1 |
Abstract interface of function to convert data of concrete Implement in concrete descendants. Parameters
|
|||
0..1 |
from_rm ( |
Abstract procedure to create an Implement in concrete descendants. |
2.2. Base Model Package
The following UML diagram shows the SIM base
package defining S_XXX
types corresponding to the Base base
package types.
sm.simplified_im_b.base
package2.2.1. Class Definitions
2.2.1.1. S_OBJECT_REF Class
Class |
S_OBJECT_REF |
|
---|---|---|
Description |
||
Attributes |
Signature |
Meaning |
0..1 |
id_namespace: |
Equivalent of |
0..1 |
id_type: |
Equivalent of |
1..1 |
id: |
2.2.1.3. S_GENERIC_ID Class
Class |
S_GENERIC_ID |
|
---|---|---|
Description |
||
Inherit |
||
Attributes |
Signature |
Meaning |
1..1 |
scheme: |
3. SIM-B Data types Package
3.1. Overview
The following UML diagram shows the SIM rm.data_types
package defining S_XXX
types corresponding to the RM rm.data_types
package types.
sm.simplified_im_b.rm.data_types
package3.2. Serial Formats
3.2.1. S_DV_TEXT
The following shows the SDT serial formats for an S_DV_TEXT
instance:
3.2.2. S_DV_CODED_TEXT
The following shows the SDT serial formats for an S_DV_CODED_TEXT
instance:
3.2.2.2. Path structure + regular value form
{
"a/b/c/d|terminology": "snomed_ct",
"a/b/c/d|code": "48694002",
"a/b/c/d|value": "anxiety"
}
3.2.3. S_DV_QUANTITY
The following shows the SDT serial formats for an S_DV_QUANTITY
instance:
3.2.3.2. Path structure + regular value form
{
"a/b/c/d|magnitude": 125,
"a/b/c/d|units": "mm[Hg]",
"a/b/c/d|xx": "xx_val", -- other DvQ fields
"a/b/c/d|yy": "yy_val"
}
3.3. Class Definitions
3.3.1. S_DATA_VALUE Class
Class |
S_DATA_VALUE (abstract) |
|
---|---|---|
Description |
Simplified RM form of |
|
Inherit |
||
Functions |
Signature |
Meaning |
1..1 |
to_rm ( |
|
0..1 |
from_rm ( |
3.3.2. S_DV_IDENTIFIER Class
Class |
S_DV_IDENTIFIER |
|
---|---|---|
Description |
Simplified RM form of |
|
Inherit |
3.3.3. S_DV_TEXT Class
Class |
S_DV_TEXT |
|
---|---|---|
Description |
Simplified RM form of |
|
Inherit |
||
Attributes |
Signature |
Meaning |
1..1 |
value: |
(unchanged from RM) |
3.3.4. S_DV_CODED_TEXT Class
Class |
S_DV_CODED_TEXT |
|
---|---|---|
Description |
Simplified RM form of |
|
Inherit |
||
Attributes |
Signature |
Meaning |
1..1 |
code: |
Converted from |
1..1 |
terminology: |
Converted from |
3.3.5. S_CODE_PHRASE Class
Class |
S_CODE_PHRASE |
|
---|---|---|
Description |
Simplified RM form of |
|
Inherit |
||
Attributes |
Signature |
Meaning |
1..1 |
code: |
Converted from |
1..1 |
terminology: |
Converted from |
3.3.6. S_DV_PARSABLE Class
Class |
S_DV_PARSABLE |
|
---|---|---|
Description |
Simplified RM form of |
|
Inherit |
||
Attributes |
Signature |
Meaning |
1..1 |
value: |
Converted from |
1..1 |
formalism: |
Converted from |
3.3.7. S_DV_QUANTITY Class
Class |
S_DV_QUANTITY |
|
---|---|---|
Description |
Simplified RM form of TODO: define |
|
Inherit |
3.3.8. S_DV_COUNT Class
Class |
S_DV_COUNT |
|
---|---|---|
Description |
Simplified RM form of TODO: define |
|
Inherit |
3.3.9. S_DV_PROPORTION Class
Class |
S_DV_PROPORTION |
|
---|---|---|
Description |
Simplified RM form of TODO: define |
|
Inherit |
4. SIM-B Structures
4.1. Data Structures Package
The following UML diagram shows the SIM rm.data_structures
package defining S_XXX
types corresponding to the RM rm.data_structures
package types.
sm.simplified_im_b.rm.data_structures
package4.1.1. Class Definitions
4.1.1.1. S_EVENT Class
Class |
S_EVENT (abstract) |
|
---|---|---|
Description |
Simplified RM form of |
|
Inherit |
||
Attributes |
Signature |
Meaning |
1..1 |
time: |
Converted from |
0..1 |
Converted from |
|
0..1 |
Converted from |
4.1.1.2. S_POINT_EVENT Class
Class |
S_POINT_EVENT |
|
---|---|---|
Description |
Simplified RM form of |
|
Inherit |
4.1.1.3. S_INTERVAL_EVENT Class
Class |
S_INTERVAL_EVENT |
|
---|---|---|
Description |
Simplified RM form of |
|
Inherit |
||
Attributes |
Signature |
Meaning |
1..1 |
width: |
Converted from |
0..1 |
sample_count: |
(unchanged from RM) |
1..1 |
math_function: |
Converted from |
4.1.1.4. S_ITEM Class
Class |
S_ITEM (abstract) |
|
---|---|---|
Description |
Simplified RM form of |
|
Inherit |
4.1.1.5. S_CLUSTER Class
Class |
S_CLUSTER |
|
---|---|---|
Description |
Simplified RM form of |
|
Inherit |
||
Attributes |
Signature |
Meaning |
0..1 |
(unchanged from RM) |
4.1.1.6. S_ELEMENT Class
Class |
S_ELEMENT |
|
---|---|---|
Description |
Simplified RM form of |
|
Inherit |
||
Attributes |
Signature |
Meaning |
0..1 |
value: |
Contains a converted form of original |
0..1 |
null_flavour: |
Converted from |
4.2. Common Package
The following UML diagram shows the SIM rm.common
package defining S_XXX
types corresponding to the RM rm.common
package types.
sm.simplified_im_b.rm.common
package4.2.1. Class Definitions
4.2.1.1. S_LOCATABLE Class
Class |
S_LOCATABLE (abstract) |
|
---|---|---|
Description |
Simplified RM form of |
|
Inherit |
||
Attributes |
Signature |
Meaning |
1..1 |
name: |
(unchanged from RM) |
0..1 |
(unchanged from RM) |
|
0..1 |
feeder_audit: |
(unchanged from RM) |
0..1 |
archetype_details: |
4.2.1.2. S_ARCHETYPED Class
Class |
S_ARCHETYPED |
|
---|---|---|
Description |
Simplified RM form of |
|
Attributes |
Signature |
Meaning |
1..1 |
archetype_id: |
Converted from |
0..1 |
template_id: |
Converted from |
0..1 |
rm_version: |
(unchanged from RM) |
4.2.1.3. S_LINK Class
Class |
S_LINK |
|
---|---|---|
Description |
Simplified RM form of |
|
Inherit |
||
Attributes |
Signature |
Meaning |
1..1 |
meaning: |
Converted from TODO: what if original was coded? |
1..1 |
type: |
Converted from TODO: what if original was coded? |
1..1 |
target: |
Converted from |
4.2.1.4. S_FEEDER_AUDIT Class
Class |
S_FEEDER_AUDIT |
|
---|---|---|
Description |
Simplified RM form of |
|
Inherit |
||
Attributes |
Signature |
Meaning |
1..1 |
originating_system_audit: |
Converted from TODO: merge into |
0..1 |
original_content: |
Converted from TODO: what happens for scanned doc images etc, which are presumably |
0..1 |
feeder_system_item_id: |
(unchanged from RM) TODO: Web template attribute name is singular form of name in RM - probably going to be confusing. |
0..1 |
originating_system_item_id: |
(unchanged from RM) TODO: Web template attribute name is singular form of name in RM - probably going to be confusing. |
4.2.1.5. S_FEEDER_AUDIT_DETAILS Class
Class |
S_FEEDER_AUDIT_DETAILS |
|
---|---|---|
Description |
Simplified RM form of TODO: removes 4 attributes from original RM form - lossy copy? |
|
Attributes |
Signature |
Meaning |
1..1 |
system_id: |
Converted from |
1..1 |
version_id: |
Converted from |
4.2.1.6. S_PARTY_PROXY Class
Class |
S_PARTY_PROXY |
|
---|---|---|
Description |
Simplified RM form of |
|
Inherit |
||
Attributes |
Signature |
Meaning |
0..1 |
id: |
Equivalent of |
0..1 |
id_namespace: |
Equivalent of |
0..1 |
id_scheme: |
Equivalent of |
4.2.1.7. S_PARTY_IDENTIFIED Class
Class |
S_PARTY_IDENTIFIED |
|
---|---|---|
Description |
Simplified RM form of TODO: |
|
Inherit |
||
Attributes |
Signature |
Meaning |
1..1 |
name: |
(unchanged from RM) |
4.2.1.8. S_PARTICIPATION Class
Class |
S_PARTICIPATION |
|
---|---|---|
Description |
Simplified RM form of |
|
Inherit |
||
Attributes |
Signature |
Meaning |
1..1 |
id: |
Converted from |
0..1 |
mode: |
Converted from |
1..1 |
function: |
Converted from |
4.2.1.9. S_PARTICIPATION_IDENTIFIED Class
Class |
S_PARTICIPATION_IDENTIFIED |
|
---|---|---|
Description |
Simplified RM form of |
|
Inherit |
||
Attributes |
Signature |
Meaning |
1..1 |
name: |
Converted from |
4.3. Composition Package
The following UML diagram shows the top-level SIM rm.composition
package defining S_COMPOSITION
, S_SECTION
and the S_ENTRY
types.
sm.simplified_im_b.rm.composition
package4.3.1. Class Definitions
4.3.1.1. S_COMPOSITION Class
Class |
S_COMPOSITION |
|
---|---|---|
Description |
Simplified RM form of |
|
Inherit |
||
Attributes |
Signature |
Meaning |
1..1 |
content: |
(unchanged from RM) |
1..1 |
composer: |
Converted to |
1..1 |
language: |
Converted from |
1..1 |
territory: |
ISO3166-1 country code to be used for composition territory (e.g. "GB", "DE", …). |
0..1 |
category: |
Value of Composition |
0..1 |
context: |
4.3.1.2. S_EVENT_CONTEXT Class
Class |
S_EVENT_CONTEXT |
|
---|---|---|
Description |
Simplified RM form of |
|
Inherit |
||
Attributes |
Signature |
Meaning |
1..1 |
time: |
Converted from |
0..1 |
end_time: |
Converted from |
0..1 |
location: |
(unchanged from RM) |
0..1 |
participations: |
(unchanged from RM) |
0..1 |
health_care_facility: |
(unchanged from RM) |
0..1 |
setting: |
(unchanged from RM) |
0..1 |
Converted from |
4.3.1.3. S_CONTENT_ITEM Class
Class |
S_CONTENT_ITEM (abstract) |
|
---|---|---|
Description |
Simplified RM form of |
|
Inherit |
4.3.1.4. S_SECTION Class
Class |
S_SECTION |
|
---|---|---|
Description |
Simplified RM form of |
|
Inherit |
||
Attributes |
Signature |
Meaning |
0..1 |
items: |
(unchanged from RM) |
4.3.1.5. S_ENTRY Class
Class |
S_ENTRY (abstract) |
|
---|---|---|
Description |
Simplified RM form of |
|
Inherit |
||
Attributes |
Signature |
Meaning |
0..1 |
subject: |
Converted to |
0..1 |
provider: |
Converted to |
0..1 |
other_participations: |
(unchanged from RM) |
4.3.1.6. S_ADMIN_ENTRY Class
Class |
S_ADMIN_ENTRY |
|
---|---|---|
Description |
Simplified RM form of |
|
Inherit |
||
Attributes |
Signature |
Meaning |
1..1 |
Converted from |
4.3.1.7. S_CARE_ENTRY Class
Class |
S_CARE_ENTRY (abstract) |
|
---|---|---|
Description |
Simplified RM form of |
|
Inherit |
||
Attributes |
Signature |
Meaning |
0..1 |
Converted from |
4.3.1.8. S_OBSERVATION Class
Class |
S_OBSERVATION |
|
---|---|---|
Description |
Variant of |
|
Inherit |
||
Attributes |
Signature |
Meaning |
0..1 |
Converted from |
|
0..1 |
Converted from |
|
0..1 |
history_origin: |
For multi-event series, converted from TODO: should be called |
0..1 |
history_period: |
For multi-event series, converted from TODO: should be called |
0..1 |
For multi-event series, converted from TODO: should be called |
|
0..1 |
history_duration: |
For multi-event series, converted from TODO: should be called |
0..1 |
state_origin: |
For multi-event series, converted from |
0..1 |
state_period: |
For multi-event series, converted from |
0..1 |
For multi-event series, converted from |
|
0..1 |
state_duration: |
For multi-event series, converted from |
4.3.1.9. S_EVALUATION Class
Class |
S_EVALUATION |
|
---|---|---|
Description |
Simplified RM form of |
|
Inherit |
||
Attributes |
Signature |
Meaning |
1..1 |
Converted from |
4.3.1.10. S_INSTRUCTION Class
Class |
S_INSTRUCTION |
|
---|---|---|
Description |
Simplified RM form of |
|
Inherit |
||
Attributes |
Signature |
Meaning |
0..1 |
narrative: |
Converted from |
0..1 |
expiry_time: |
Converted from |
0..1 |
activities: |
(unchanged from RM) |
4.3.1.11. S_ACTIVITY Class
Class |
S_ACTIVITY |
|
---|---|---|
Description |
Simplified RM form of |
|
Attributes |
Signature |
Meaning |
0..1 |
timing: |
Converted from |
0..1 |
action_archetype_id: |
(unchanged from RM) |
1..1 |
Converted from |
4.3.1.12. S_ACTION Class
Class |
S_ACTION |
|
---|---|---|
Description |
Simplified RM form of |
|
Inherit |
||
Attributes |
Signature |
Meaning |
1..1 |
time: |
Converted from |
1..1 |
Converted to |
|
1..1 |
current_state: |
Converted from |
0..1 |
careflow_step: |
Converted from |
0..1 |
transition: |
Converted from |
0..1 |
instruction_id: |
Converted from |
0..1 |
activity_id: |
Converted from |
4.4. Application Context Model
This section defines an 'application context model' that formalises various defaults and other data settings that enable an openEHR client application to more conveniently create larger data sets (Composition structures) to commit to an openEHR EHR through the openEHR REST API.
sm.app_context
package4.4.2. APP_CONTEXT Class
Class |
APP_CONTEXT |
|
---|---|---|
Description |
Class representing application context data items that may be set for a |
|
Attributes |
Signature |
Meaning |
1..1 |
language: |
ISO639-1 language code to be used for Composition language (e.g. "en", "de", …). Equivalent of RM To RM: match term text from openEHR From RM: |
1..1 |
territory: |
ISO3166-1 country code to be used for composition territory (e.g. "GB", "DE", …). Equivalent of RM To RM: match term text from openEHR country vocabulary; create From RM: |
1..1 |
composer_name: |
Name of the person who composed the Composition. ISO3166-1 country code to be used for composition territory (e.g. "GB", "DE", …). Equivalent of RM To RM: xxx. From RM: if |
0..1 |
composer_id: |
Equivalent of |
1..1 |
time: |
Default value to be used for:
If not specified current time will be used. Converted from |
0..1 |
end_time: |
Equivalent of TODO: check: this is just a copy of /context/end_time? From RM: copy of |
0..1 |
category: |
Value of Composition To RM: match term text from From RM: TODO: check: this is just a copy of /category; needed here? |
0..1 |
setting: |
Equivalent to To RM: obtain code definition from openEHR From RM: TODO: check: this is just a copy of /context/setting; needed here? TODO: There are 2 new codes in EhrScape ?not in openEHR terminology:
|
0..1 |
history_origin: |
Default value for |
0..1 |
id_namespace: |
Default namespace for identifier references derived from |
0..1 |
id_scheme: |
Default |
0..1 |
provider_name: |
Equivalent of Default for all |
0..1 |
provider_id: |
Equivalent of Default for all |
0..1 |
Equivalent of |
|
0..1 |
Equivalent of |
|
0..1 |
Equivalent of |
|
0..1 |
Equivalent of |
|
0..1 |
Equivalent of |
|
0..1 |
action_time: |
Default value for all TODO: is this default really needed - having 2 ACTIONs in same commit probably uncommon. Easier to just include in compressed S_ACTION. |
0..1 |
action_ism_transition_current_state: |
Default value for TODO: is this default really needed - having 2 ACTIONs in same commit probably uncommon. Easier to just include in compressed S_ACTION. |
0..1 |
instruction_narrative: |
Default for all |
0..1 |
healthcare_facility: |
Equivalent of |
0..1 |
activity_timing: |
Default for all TODO: really needed, since multiple INSTRUCTIONs in commit with same timing would be unlilkely. |
0..1 |
location: |
Equivalent of |
0..1 |
workflow_id: |
Default value for |
4.4.3. APP_COMPOSITION Class
Class |
APP_COMPOSITION |
|
---|---|---|
Description |
Specialised form of |
|
Inherit |
||
Attributes |
Signature |
Meaning |
0..1 |
ctx: |
Context data for this |
5. Transformation Rules
This section contains rules defining the formal relationship between the SIM-B and the openEHR RM and other models on which it is based.
5.1. Composition Package
RM class | RM Path | SIM class | SIM Path | Constraint conversion rule |
---|---|---|---|---|
|
|
(default) |
||
|
|
|
|
|
|
|
|||
|
|
(default) |
||
|
|
(default) |
||
|
|
(default) |
||
|
|
(default) |
||
|
|
(default) |
||
|
|
(default) |
||
|
|
(default) |
||
|
|
(default) |
||
|
|
(default) |
||
|
|
(default) |
||
|
|
|
|
create |
|
|
create |
||
|
|
|
|
|
|
|
|
||
|
|
|
|
create |
|
|
|||
|
|
default |
||
|
|
|||
|
|
default |
||
|
|
|||
|
|
n/a |
||
|
|
|
5.2. Common Package
RM class | RM Path | SIM class | SIM Path | Constraint conversion rule |
---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5.3. Data Structures Package
RM class | RM Path | SIM class | SIM Path | Constraint conversion rule |
---|---|---|---|---|
|
|
|
|
create |
|
|
|
||
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
create |
|
` |
|
||
|
|
|
5.4. RM Data types Package
RM class | RM Path | SIM class | SIM Path | Constraint conversion rule |
---|---|---|---|---|
|
|
|||
|
|
skip |
||
|
|
skip |
||
|
|
skip |
||
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|||
|
|
|
6. Amendment Record
Issue | Details | Raiser | Completed |
---|---|---|---|
SM Release 1.0.0 (unreleased) |
|||
SPECSM-2. Add Simplified Information Model 'B' (SIM-B); |
openEHR SEC |