openEHR Reference Model (RM) Release 1.1.0 published

[thomas.beale]

The openEHR Specifications Editorial Committee (SEC) has published RM Release 1.1.0 today.

Change-log | Issues fixed

This release brings a number of important improvements to the reference model including:

• the new DV_SCALE data type, supporting scales/scores containing decimal numbers;
• addition of a preferred_term field to the coded text data type;
• addition of archetypeable meta-data to Folder objects;
• addition of unlimited Folder hierarchies to an EHR;
• addition of free meta-data field to Feeder system audit, to aid integration;
• added null_reason field to ELEMENTobjects (i.e. any archetype leaf node);
• support any units system and units display text in Quantities.

We hope this proves useful for the community, and would like to thank all the implementers for the feedback that led to this release, as well as the SEC members and others who helped create it.

[Leuschner (Pedro Leuschner)]

That’s a lot of work, @thomas.beale and all. Thanks! I can’t see the change-log, release notes and issue’s fixed (Jira wall). Still working on it?

[thomas.beale]

You’re right, I just tested this. It appears to be an Atlassian problem. We have raised a support issue there, and will try to find a workaround.

[sebastian.iancu]

For those that have no proper access to JIRA, or somehow the release view is not working as expected, here is a list of release notes:

Problem Report

• [SPECPR-62] - Add a ‘reason for null’ text attribute in the Reference model
• [SPECPR-85] - Add some place to put data on the FOLDER object
• [SPECPR-251] - Clarify usage of UCUM for DV_QUANTITY
• [SPECPR-271] - Extend FEEDER_AUDIT_DETAILS class with “other_details” (ITEM_STRUCTURE)
• [SPECPR-322] - Document the composition uid value
• [SPECPR-44] - Add support for Real values in DV_ORDINAL
• [SPECPR-88] - Correction to COMPOSITION.category description
• [SPECPR-132] - Unable to carry rubric in TERM_MAPPING
• [SPECPR-165] - Add rubric attribute to CODE_PHRASE
• [SPECPR-204] - Wrong ISM transition name in EHR IM text
• [SPECPR-311] - preceding_version_id should be preceding_version_uid
• [SPECPR-335] - Define context of “persistent” COMPOSITION.category
• [SPECPR-344] - Wrong class definition in Support Information Model documentation
• [SPECPR-355] - Disjoint merging advice in COMMON problematic for persistent compositions

Change Request

• [SPECRM-19] - Add support for Real values with DV_SCALE
• [SPECRM-55] - Add folders:LIST<OBJECT_REF> on EHR
• [SPECRM-56] - Add archetypable details meta-data to FOLDER
• [SPECRM-60] - Add Version lifecycle state machine to RM
• [SPECRM-61] - Add reference-retrieving functions to EHR class
• [SPECRM-64] - Add CODE_PHRASE.preferred_term optional field to carry rubric (preferred term) text
• [SPECRM-65] - Add units_system and units_display_name attributes to DV_QUANTITY
• [SPECRM-74] - Add other_details meta-data field to FEEDER_AUDIT_DETAILS
• [SPECRM-77] - Add ELEMENT.null_reason
• [SPECRM-85] - Correct typographical errors in preceding_version_uid in Change Control package
• [SPECRM-88] - Improve documentation relating to use of uid in versioning and LOCATABLE descendants.
• [SPECRM-89] - Add ‘episodic’ type to COMPOSITION.category
• [SPECRM-92] - Correct numerous minor typographical and formatting errors.
• [SPECRM-93] - Adjust advice on merging persistent compositions
• [SPECRM-94] - Correct arithmetic and comparison functions in Data Types
• [SPECRM-96] - Consistently support negative durations
• [SPECRM-97] - Define data validity rules for Versions with lifecycle_state = incomplete

[erik.sundvall]

Hi!

I believe we may have missed describing the new ITEM_TAG class in the spec documents, it is in the UML: https://specifications.openehr.org/releases/UML/latest/index.html#Architecture___19_0_3_8fe028d_1588000883570_669310_5583

…and it is listed in https://specifications.openehr.org/classes but the link there goes to https://specifications.openehr.org/releases/RM/latest/common.html#_item_tag_class where #_item_tag_class anchor does not exist and there is no text about tags in that document.

There are some hints about tags in the documentation about the EHR class “tags” attribute though, see https://specifications.openehr.org/releases/RM/latest/ehr.html#_ehr_class

[thomas.beale]

Ah - that is an error - I forgot to remove these classes from the released UML source files (from which the site is generated) when we pushed the tag CR up to Release 1.2.0. Will fix…

[thomas.beale]

This is now corrected - Release 1.1.0 Ehr IM.

Global UML site - EHR class.

[pablo (Pablo Pazos)]

Quick question: Pieter mentioned that the specs allow negative DV_DURATION, but ISO8601 doesn’t seem to allow negative durations. Can someone confirm if we support negative durations and why?

REF: https://github.com/openEHR/archie/issues/209#issuecomment-707070720

[ian.mcnicoll]

Hi Pablo,

Duration data type

Hi all, We have always expressed the clinical notion ‘age’ as DV_DURATION. It was one of the first things I remember Sam telling me… ie the duration of time since birth. BUT there is a clinical situation where you can have a negative ‘adjusted age’ where there is a premature infant, now chronologically 2 months old but born 3 months premature - they are said to have an adjusted, or corrected, age of -1 month. Clinically this is important when related to expected development/behaviour/functiona…

Ian

[pablo (Pablo Pazos)]

Thanks Ian, the usage is clear for me. My question is about the data representation including the sign in the duration expression, since it seems that is not ISO8601 compliant.

In the model we have: (https://specifications.openehr.org/releases/RM/latest/data_types.html#_overview_5)

DV_DURATION

• value: String <<< this should be ISO8601 valid duration expression

A different way of modeling this for the use case/clinical modeling with compliance to ISO8601 would be:

DV_DURATION

• value: String << compliant with ISO8601 duration expression
• is_negative: Boolean <<< removes the sign from the expression to a different field

Note: I don’t have the full ISO8601 specification, so if someone that has it can check if the sign in the expression is valid or not, it will help to know if we are actually doing something we shouldn’t

[thomas.beale]

Hi Pablo,
DV_DURATION is based on Iso8601_duration, from here in the Foundation types. This ensures it is a valid ISO8601 duration string. You already knew that I guess. You can see there an operation negative() that generates the negated form of a Iso 8601 duration value. However, I think you are right - we have neglected to add a field is_negative to actually represent the negation, which comes for free with Integers and Reals etc. I’ll fix this ASAP.

[pablo (Pablo Pazos)]

Hi Thomas, you are spot on! That was exactly my question and possible solution

Thanks.