Content Comparison

Main Agenda

10 min

Opening,

Various aspects

ALL

SEC Jira board.

• SEC meeting face2face 2025

• “Adopt your ticket”

Sebastian Iancu Joost Holslag

• Jira Legacy
  server System Jira serverId 7788407e-95fd-3d19-96c6-946a2bd486dc key SPECTERM-30

• Jira Legacy
  server System Jira serverId 7788407e-95fd-3d19-96c6-946a2bd486dc key SPECBASE-39

• Jira Legacy
  server System Jira serverId 7788407e-95fd-3d19-96c6-946a2bd486dc key SPECPR-422

• Jira Legacy
  server System Jira serverId 7788407e-95fd-3d19-96c6-946a2bd486dc key SPECPR-449

• Jira Legacy
  server System Jira serverId 7788407e-95fd-3d19-96c6-946a2bd486dc key SPECAM-90

• todo:

  Jira Legacy
  server System Jira serverId 7788407e-95fd-3d19-96c6-946a2bd486dc key SPECBASE-35

• see https://discourse.openehr.org/t/upcoming-base-1-3-0/6139

ADL2

Ian McNicoll

https://specifications.openehr.org/releases/AM/latest/ADL2.html#_annotations_section

• Ian McNicoll todo check conversion algorithm from ADL1.4 to ADL2

• question where do we put multi-languages vs uni-language annotation.

ADL1.4→2 Annotations

todo: suggest RESOURCE_ANNOTATION.documentation hash key should support '*' as language agnostic annotation

todo: a new SPECAM for

1. Add comment attribute in ARCHETYPE_TERM as formal attribute

Archived spec status

Sebastian Iancu

archived rather then retired

https://discourse.openehr.org/t/task-planning-specs/6154

https://openehr.org/specification-program/

https://openehr.org/change-process/

https://openehr.org/release-strategy/

• keep retired as it means archived, deprecated
  definition: retired ‘activity status’ indicates that the specification (or its specific version) was superseded either by a new version or a new specification. Even though the specification (or its specific version) with retired status can be implemented and used, there is a recommended alternative which should be considered instead.

• add inactive as a new dimension, and describe it
  definition: inactive ‘activity status’ indicates that the specification (or its specific version) is no longer actively being worked on by the SEC. This could be due to various reasons, such as lack of resources within the SEC to work on the specification (or its specific version) or due to lack of adoption by relevant stakeholders.

Re change process, release strategy and activity status:
I chose the term activity status as the name for the trait/aspect/dimension of specifications. It is open to objections and improvements of course.

Relation to change process:
I think activity status is related to change process as follows: it has to start as active (no need to indicate explicitly) and if the spec is not developed until its stable state for any reason, it can then be marked as inactive. I.e. it is no longer worked on. At or after the Stable lifecycle state, it can be in active (implicit), inactive(explicit) or retired(explicit) states. There is an overlap between the lifecycle state retired and activity status state retired so using deprecated for one of these may help with that, but I still think these are different dimensions of assessment for a spec.

It does not make sense to me for a spec to be in retired activity status state before it reaches Stable lifecycle state, due to how we defined retired above: a spec should pass some threshold to be retired, with one or more successors. It can become inactive at any point in its lifecycle though.

A spec (or its specific version) in inactive state can be switched to an active state (simply by removing the inactive status) and this switch may or may not accompany a change in lifecycle state (inactive spec in development state becomes active, and state changes to trial at the same time, or not)

If the lifecycle state of a spec becomes retired, then is activity status also has to become retired and that’s the only activity status state allowed: a retired lifecycle state is (I’m assuming) terminal for a spec and marking it as inactive contradicts the semantics we assigned to retired, and active also has the same problem, so it can only be retried in activity status, if the lifecycle state is retired.

Relation to release strategy:
The only consideration I could come up in relation to release strategy is whether or not changing the activity status requires a new release and my gut feeling is that it does not. I.e. an existing release can have its activity status turned to inactive at any point.

• 09 Febr: see resulting Introducing an intermediate Specification Lifecycle State between "Stable" and "Retired" - proposal New "Archived" or "Frozen" Specification Lifecycle State

DV_ORDINAL

Joost Holslag

• see previous comments on this in dec 2024

• Joost Holslag reach out to clinical, Rachel will organize a strategic meeting after 21 January

• discussion about DV_ORDINAL should we moved to one of a separate (“hands-on”) meeting (SEC meeting) after 21 January

• todo: Sebastian Iancu ask Rachel about SEC x CPB meeting

Constraining and patterns for DV_EHR_URI values

Severin Kohler

see previous meeting notes

After releasing the 1.0 of the FHIR connect Severin would like it to be maintained by the SEC. Joost Holslag feels it should be part of the openEHR spec. (Or ideally an artefact jointly maintain with HL7)

• Severin Kohler is looking for maintenance team

Term Binding strengt

Ian McNicoll

• the question is if we want to proceed on this ticket with CRs

  • the SEC agrees that it makes sense to analyze this and come up with CR proposals

  • todo: SEC members should comment on the tickets

  • Borut Jures there is a ‘value_constraint’ field for this in BMM, e.g.

    • ["Multimedia"] = < name = <"Multimedia"> ancestors = <"Encapsulated"> properties = < ["alternate_text"] = (P_BMM_SINGLE_PROPERTY) < name = <"alternate_text"> type = <"String"> > ["data"] = (P_BMM_CONTAINER_PROPERTY) < name = <"data"> type_def = < container_type = <"Array"> type = <"Byte"> > cardinality = <|>=0|> > ["media_type"] = (P_BMM_SINGLE_PROPERTY) < name = <"media_type"> type_ref = < type = <"Terminology_code"> value_constraint = <"iana_media-types"> > is_mandatory = <True> >

Relax Coding invariants??

e.g. EVENT_CONTEXT.setting
https://specifications.openehr.org/releases/RM/Release-1.1.0/ehr.html#_event_context_class

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

Recommendations to remove these RM attribute constraints to make the current codelists optional

3.2.6. Participation Function

3.2.8. Participation Mode

3.2.7. Null Flavours (consider updating/referencing the latest HL7 equivalent)

3.1.7. Normal Statuses (consider updating/referencing the latest HL7 equivalent)

3.2.11. Subject Relationship

3.2.12. Term Mapping Purpose

3.2.14. Setting (clinical setting)

More problematic?

3.1.4. Media Types

3.1.5. Compression Algorithms

3.1.6. Integrity Check Algorithms