2025-03-31 SEC Call notes

10 min

Opening,

Various aspects

ALL

SEC Jira board.

• SEC meeting face2face 2025

• “Adopt your ticket”

•  

• @Rong Chen CDS WG update

  • still looking for a weekly meeting

  • scope:

    • short-term: GDL2.1, rest api for GDL

    • long-term: machine learning, care plans, task generation, personalized care plan

• @Joost Holslag migration from old website has some problems

  • uri strategy or archiving strategy

• @Seref Arikan about face2face

  • FHIR DEV days in 1st week June or

  • EHRCon Barcelona October

  • todo: @Sebastian Iancu ask on pref on discourse

@Sebastian Iancu

• https://openehr.atlassian.net/browse/SPECAM-90

• the ADL_CODE_DEFINITION should accept both id-code and at-code values https://specifications.openehr.org/releases/AM/development/AOM2.html#_adl_code_definitions_class

info:

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

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

todo:

• https://openehr.atlassian.net/browse/SPECBASE-35

  • https://discourse.openehr.org/t/archetype-id-value-syntax-for-the-upcoming-base-1-3-0/6139/41

• https://openehr.atlassian.net/browse/SPECBASE-30 :

  • Template ID in Composition Examples

  • @Ian McNicoll we add v1 to template-name, and v1-alpha in case of development

• @Ian McNicoll todo check template-id conversion algorithm from ADL1.4 to ADL2

• https://openehr.atlassian.net/browse/SPECAM-91

• RESOURCE_ANNOTATION.documentation:

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

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

  • a new SPECAM for

    1. Add comment attribute in ARCHETYPE_TERM as formal attribute https://specifications.openehr.org/releases/AM/development/AOM2.html#_archetype_term_class

    2. ADL1.4→2 Annotations

    3. @Mattijs Kuhlmann a better solution would be a whole different section rather then *

    4. @Ian McNicoll the documentation is multi-lingual (this needs to be explained in specs) and for technical we should add a new attribute to https://specifications.openehr.org/releases/BASE/development/resource.html#_resource_annotations_class

       technical: Hash<String, Hash<String, String>>

• adl2.4 release does not depends on a converter for template 1.4

Archived spec status

@Sebastian Iancu

• update doc with feedback; consider “Paused”

• move main website info about change process to specification website

• see previous meeting notes: https://discourse.openehr.org/t/task-planning-specs/6154

New "Paused" Specification Lifecycle State

• agree with Paused, need more acceptance on the wiki-page

@Severin Kohler

INTG component

• Suggestion to add INTG component to the spec as a 4th sibling under SM component, after PROC/CDS

• SEC group agrees, nobody from present is against the proposal

Term Binding strengt

@Ian McNicoll

https://openehr.atlassian.net/browse/SPECPR-439

• 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> >

• @Ian McNicoll suggestion to relax RM invariants, except for strength is “required”

YAML

@Matija Polajnar @Sebastian Iancu

https://discourse.openehr.org/t/yaml-canonical-compositions/6606

https://discourse.openehr.org/t/bmm-as-yaml/5721

Archetypes in YAML