2025-05-26 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”

@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: Find out exact times on 15th

@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

Archived spec status

@Sebastian Iancu

• update doc with feedback; consider “Paused”

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

• move main website info about change process to specification website

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

https://openehr.atlassian.net/wiki/spaces/spec/pages/2789638199

• what happened to license after specs paused

• from SEC to international board to suggest the license change, allowing cloning/forking with creative commons condition without openEHR label (Rong to draft something on this)

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

Conformance testing?

Ian’s update on postman tests

@Ian McNicoll smallish conformance testing for IHE connectathon Vienna.
Functional testing: it is doing what it needs, make sure create ehr works, etc.
Strict testing: less clear on criteria
Might be able to get first version week starting Jun 2, 2025
@Sebastian Iancu maybe use levels, i.e. level1 is the least demanding

MagicDraw

@Severin Kohler

Long term plan for UML diagrams and use of MagicDraw

@Severin Kohler spec is not transparent and difficult to know where to make changes. Even some regular text comes from MD? Invariants should not be a blocker for the move.
How do we make transition from MD to something new?
Maybe use xmi to plantuml as first round?
@Sebastian Iancu Use BMM for single source of truth and generate asciidoc and diagram files out of those. Will share a diagram on spec processing. Use yml/json serialisation of BMM. Will do export MD to BMM.
Check with@Thomas Beale what is missing in BMM that is present in MD?
@Joost Holslag BMM should not be the ultimate source of truth as it is openEHR specific. Could we use json-schema instead?
@Borut Jures can give SEC access to cli tool to generate diagrams out of BMMs. Use a subdomain on openehr.org for diagrams site? Credit to BorutJures.
@Erik Sundvall and @Joost Holslag can help with manually providing layout/rendering hints to plant-UML to make certain diagrams (e.g. used as figures in specs) somewhat more pedagogical/beautiful.