2023-06-05/07 Barcelona SEC Meeting

Jun 5, 2023

• @Sebastian Iancu

• @Sebastian Garde

• @Diego Bosca

• @Joost Holslag

• @Sidharth Ramesh

• @Pieter Bos

• @Seref Arikan

• @Ian McNicoll

• @Birger Haarbrandt

• @Alex Vidrean

• @Bostjan Lah

• @Thomas Beale

• @Matija Polajnar

• @Erik Sundvall

• @Jake Smolka

• @Rong Chen

• @Bjørn Næss

• @Pablo Pazos

• @Shinji Kobayashi

Jun 7, 2023

• @Sebastian Iancu

• @Sebastian Garde

• @Diego Bosca

• @Joost Holslag

• @Sidharth Ramesh

• @Pieter Bos

• @Seref Arikan

• @Ian McNicoll

• @Alex Vidrean

• @Thomas Beale

• @Matija Polajnar

• @Erik Sundvall

• @Bostjan Lah

• @Jake Smolka

• @Rong Chen

• @Birger Haarbrandt

• @Bjørn Næss

• @Pablo Pazos

• @Shinji Kobayashi

Jun 5, 2023

11:00 - 11:15

@Sebastian Iancu

Welcome / opening

11:15 - 11:35

SEC Working Groups (WG) proposal review

Agreed to have just one WG for ADL/AOM/templates; treat ‘ADL2 transition’ as a openEHR-wide discussion - potentially X-board forum and/or f2f meeting (similar to Braunschweig).

Some adjustments to other WG scopes.

Question on conformance WG responsibilities.

Add WG for RM, since not otherwise covered, including ‘episode’ modelling.

11:35 - 11:55

@Sebastian Iancu @Pablo Pazos

Specification maintenance lifecycle

skipped, due timing

11:55 - 12:20

SEC Roadmap (long and short term goals)

Should we go for ISO standardization? Complicated question, …

Roadmap:

• ADL2 adoption

  • Sept 2023 - Requirements/ assessment / SWOT analysis - for whole SEC / CPB

• Conformance

  • end 2023

• REST v2

  • end 2023 / beginning 2024

12:20 - 13:00

ADL2 transition - first round of discussions

skipped, due timing

Jun 7, 2023

9:00 - 9:15

Opening / Agenda setting

• the WGs should use Jira filters to scan and take ownership on SPECPR issues

• the remaining ticket will be discussed/assigned during SEC meetings

9:15 - 10:00

Specification priorities, goals and scopes for WG

Reducing workload, spec lifecycle review, deprecation roadmap, new spec-incubators definition

10:00 -10:45

ADL2 transition - 2nd round of dsicussions

Related background material:

• ADL2 Evolution - ADL - Confluence (atlassian.net)

• Internal SEC forum thread (with unfortunate “3” in name) https://discourse.openehr.org/t/towards-adl3/3930

Notes from discussion:

• see confluence page in ADL space (@Pieter Bos will make it)

11:00 - 11:30

RM 1.2 (including Demographic RM)

• work out the RM 1.2 CRs

• SYSTEM should be also added

• Episode further work out with Joost and Jan on the modeling level to analyse features and use-cases

•  

11:30 - 12:00

@Sebastian Iancu

REST API next release

+ @Joost Holslag : I’d like to discuss simple data formats for api: webtemplate/tdd/OpenAPI etc

+ @Sidharth Ramesh : eventing standard for openEHR

+ @Erik Sundvall Addting TAGs support in REST API

• data formats…

• eventing standard…

• REST API for openEHR Tags package (ITEM_TAG). Questions to the SEC:
  1. Would the SEC be comfortable with letting the REST WG detail something along the following points?
  2. What thoughts would you like to send along into that work?

  Open

  

  • Background: In e.g. the Swedish openEHR RFI, TAGs combined with ABAC have surfaced as one of the most interesting ways to solve complex Swedish legal requirements regarding access control. In use cases like that one would like want/need to have some ways of adding tags in the same atomic transaction as adding/modifying COMPOSITIONs (and likely other versioned objects).

  • A JSON (and likely an XML) serialisation format for ITEM_TAG needs to be specified. (Perhaps it already exists?)

  • An API to modify ITEM_TAGs independently of changes to versioned objects (for non-atomic use cases) is needed. Perhaps some validation rules also, e.g. not allowing tagging of non-existing objects?

  • One possible way to modify the REST spec to optionally allow combined tag+composition atomic modifications is to allow contributing also ITEM_TAG objects in the .../contribution POST call.

  • Also it would be good if the …/composition API endpoint had some convenient way of optionally setting/modifying tags atomically together with the composition creation/change, perhaps via http headers following existing patterns, so something like openEHR-ITEM_TAG: key="my_nice_key", value="...", target_path="..." (ITEM_TAG.target would be the current COMPOSTION and ITEM_TAG.owner would be the current EHR)

  • Another important thing is how to standardise the API (headers?) for using tags for filtering and querying (as defined in the tag “semantics” section). Adding stuff to AQL right now might be contentious, but allowing optional filtering via http-headers in the …/query API could be a fairly easy thing to define and add as anoptional feature to the REST ITS. Perhaps DIPS, Better and others using already using TAGS could describe what filtering operations you support and how?

• eventclouds: mini-WG with @Sidharth Ramesh @Erik Sundvall @Alex Vidrean @Sebastian Iancu perhaps somebody from Cambio + @Jake Smolka (but I missed the discussion and need to make sure this is about what I’m thinking)

12:00 - 12:20

@Sidharth Ramesh

SMART on openEHR

• @Sidharth Ramesh will bring this into REST WG, to be further worked out

12:20 - 12:40

@Ian McNicoll

Package management/ Imp Guides

• a consistent set of artefacts

• get inspiration from FHIR (ask @Ian McNicoll )

• DIPS has really nice package-management - we should invite @Bjørn Næss to present

• it is very relevant for Catalan project

• @Sidharth Ramesh https://oras.land/

• @Pieter Bos The relevant FHIR specification is at How to use for that is at

14:00 - 14:45

Conformance Strategy

14:45 - 15:30

… tbd

• JH: Care plans?

15:30 - 16:15

… tbd

• SI: AQL next release?

16:15 - 16:30

Closing

discussions about next f2f meeting 20-21 sept