2025-07-21 SEC Call notes

10 min

Opening,

Various aspects

ALL

SEC Jira board.

• SEC meeting face2face 2025, Barcelona in Oct 16-17, 15 full-day for SEC meeting?

• “Adopt your ticket”

Hard to get exact number, let’s reserver 15 places, 14th afternoon and 15th afternoon

CPB+SEC meetings

@Joost Holslag @Sebastian Iancu

@Joost Holslag (Unlicensed) joint meeting with program board and CPB on the Oct 15, rest of the day SEC. Maybe Oct 14 afternoon.
Create a discourse page to check availability for the 14th.

TODO: availability for CPB a call on week after 23 Sept to sync and prepare the face2face meeting in Oct
TODO: Find out exact times on 15th

agree/proposals:

• SEC meeting estimate 15 persons

• Rachel helps organizing with Jordi

• 14 Oct 2025 SEC after lunch time 13:00

• 15 Oct 2025 1/2 SEC, 1/2 SEC+CPB

• availability for CPB a call on week after 23 Sept to sync

All

Idea of OpenEHR Labs proposed by TB

@Erik Sundvall (@sundvall.org) - not a bad practice to make new in devel things

@Severin Kohler, @Matija Polajnar, @Seref Arikan, @Bostjan Lah, @Sebastian Iancu : not a good idea - new things can be developed naturally or in working groups and still be fully under SEC governance

Most members are against it in the current form as suggested on Discourse (discourse), but we are open to discussing with Thomas to find a suitable mode of cooperation

Governanace

@Severin Kohler

Propose to add branch policies on github, add PullRequest requirements

• @Sebastian Iancu it was a bit unhandy in the past, especially if only one editor applying changes

  • proposal is good, but it will increase complexity on change process

• @Severin Kohler @Joost Holslag but in the future we need more contributors

• @Joost Holslag we should consider this an opportunity to improve the process

• @Severin Kohler we should consider re-rendering pages after review

• @Diego Bosca it is much easier to review and give acceptance on PR then on Jira

• @Joost Holslag voting on github should make the acceptance vote on Jira (to avoid extra work and duplicates); trivial changes on github, more complex changes involving more repos can be always in JIRA

• @Sebastian Garde stick more to JIRA, but improve streamline on github

• @Diego Bosca review itself should be more in Github, formal acceptance on Jira

• @Joost Holslag

  Open

  

BMM

@Borut Jures @Sebastian Garde

https://discourse.openehr.org/t/remove-dv-quantity-property-attribute-in-bmm-files/6779/11

• we need to continue to look for a solution for this - please comment on the thread

• This should be discussed with CPB - it allows modelling time specification of type of quantity without specifying units

• @Diego Bosca there are others like this DV_PROPORTION.type

• @Severin Kohler - working on overall review of data type attributes with @Ian McNicoll, @Diego Bosca

BMM

@Sebastian Iancu

• Issues with BMM, P_BMM specifications

• UML to .bmm.json export

• https://discourse.openehr.org/t/refreshing-bmm-files/5608/13

• https://github.com/sebastian-iancu/code-generator/tree/master/code/BMM

• see also previous meeting notes https://openehr.atlassian.net/wiki/spaces/spec/pages/2978414594

• @Sebastian Iancu working on this

• @Bostjan Lah working on BMM json to adoc export so we need not rely on MagicDraw

@Sebastian Iancu

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 :

  • https://openehr.atlassian.net/wiki/spaces/spec/pages/2881060992

  • @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. https://openehr.atlassian.net/wiki/spaces/spec/pages/2728755245

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

• AUTHORED_RESOURCE for templates, FHIR connect (mappings), queries, guidelines

• Not yet used in the definition API

• original language is a mandatory attribute

• Rong/Joost organize related issues for next call

• Common already supported by tooling (CKM/template designer), better to be a formal attribute (reserved name)

  • Ian to raise CR on this

• Ian to raise PR to work on the language support for annotations

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”

• Ian to create PR on this