2023-11-15/16 Arnhem SEC Meeting

Nov 15, 2023

Genieten in de Weerd, Arnhem

9:00

door opens - installing - coffee

9:30

@Sebastian Iancu

Welcome / Agenda

Pieter Bos resigning from SEC, follow up from Nedap is Matijs - no objection from SEC members to accept him as new member.

9:45 - 10:30

@Sebastian Iancu

Jira Board

10:30 - 11:30

@Sebastian Iancu

RM 1.2.0 work, tickets, etc

• TAGS

  • path refers to AQL path (need to remove mentioning RM paths); positional predicate is not considered to be safe for json serialization/deserialization

  • add invariant that if you use path, the versioned_object should be used

  • improving text because is not clear what is the use case: searching, but also labelling nodes or compositions (@Erik Sundvall)

  • name/coding might be need to transport semantic, key might be not very clear → but suggestion is to use folders for more complex use case where you want to code the tags

  • “looks like annotations”

  • atomic way adding tags to composition in a contribution

  • offtopic: contribution is transaction unit

  • target_path in REST API uri is nasty; it might need to have an id to uniquely identify in the management operations

    • that might create the premise of having an dedicated api uri - becoming a resource

    • need to check with EhrScape API - todo @Erik Sundvall @Sebastian Iancu

  • @Pieter Bos we should check also FHIR tags, to see how is dealing with coding

    • add 0..1 code CODE_PHRASE or string - see DV_QUANTITY , but keep it simple

  • see EhrScape yaml

• SYSTEM

  • still ok adding; @Sebastian Iancu should work on it and propose it to SEC

• EPISODE

  • Ocean uses workflow_id to “group” compositions as part of an Episode

  • the consensus is that is too early to have such a type, rather use FOLDERs based on a specific (recommended) archetype, and add an implementation guide about use of this archetype+folder, potentially describe use of tags to implement episode context

  • …thus no new type

  • use of episode in a contribution is complex and we will need to define the logic of atomic contribution

    • [Addition by @Erik Sundvall: CONTRIBUTIONs have been implemented as a transactions by all vendors present at this SEC meeting, so that is not the complex thing, but might (according to @Seref Arikan's previous discussions with @Thomas Beale) need to be clarified in the spec anyway. A remaining complexity is how you link/cross-reference between several different new objects in the same CONTRIBUTION API call before the server has given them their permanent IDs. One way of doing that is that the application calling the API assigns temporary strings as IDs for the new objects and uses the same strings in references from other objects sent in the same CONTRIBUTION]

  • WG episode with clinical modeling to further identify the IG

• constraining links (@Joost Holslag )

• constrain mappings (@Ian McNicoll) on templates

  • @Joost Holslag this might be possible in adl2

• AQL should investigate adding demographic flavored functions like age(), gender(), etc -

11:45 - 12:30

@Sebastian Iancu

AQL work, tickets, etc

• TAGS

  • use functions

• FOLDERS

• SYSTEM

• EPISODE

• federative AQL

13:00 - 15:00

@Bostjan Lah @Pieter Bos

ADL 2/3

• group is wondering if we should drop the id-coding

  • apparently no impact on ckm / modeling process

  • there might be an impact on Nedap’s models an applications

  • @Erik Sundvall adding alias keys to nodes to AQL paths, and id-code could be also a key - this should be supported by RM also

  • @Bostjan Lah maybe we could use mapping attribute on locatable.name.mappings instead of adding new attribute in RM

  • @Pieter Bos Nedap will check how big of the problem is overlapping id-code with at-code; check if introducing an extra key will solve the overlapping issue

  • @Pieter Bos we should add to adl2 specs a deprecated warning to not use overlapping on numeric number

  • @Sebastian Garde once we are on ADL3 we might not support ADL2 to avoid issues

  • @Pieter Bos we should do the conversion of “all” archetypes on a single point so that we have a unique reliable id-codes

  • add syntactic sugar for adl paths items[code = 'SNOMED-CT::123456'] like items[code = 'local::at001'] where the code is the shortcut to mappings

    • @Erik Sundvall added afterwards: The syntactic sugar design likely needs some more consideration. Is it things like items[name/mapping/target='SNOMED-CT::1234567'] or items[name/mapping/target/code_string='SNOMED-CT::1234567']that was suggested to become something like items[code='SNOMED-CT::1234567'] ? If so it might be confused with DV_CODED_TEXT.defining_code (which is archetype_node_id: another CODE_PHRASE).

    • 2023-12-11 addition at/after SEC meeting: for the “human readable keys” discussed (as optional extra alternative to at/id codes) we should likely have some shorter syntactic sugar like items[#my_fancy_readable_code] or items[#'my_fancy_readable_code'] or items[@my_fancy_readable_code] or whatever

15:20 -17:00

@Bostjan Lah @Pieter Bos

ADL 2/3

• there is consensus that we are committed to ADL3

• need to store full-lineage of archetype specialization, name-spacing in ADL3 archetype/templates

• dashes does not carry any meaning (same like in v2) - change in BASE model component!?

• don’t need to do anything particular change after migration to ALD3 if you have archetype_node_id on v1 style, the dashed name we’ll not have any meaning

• for CDRs implementing ADL v3, store the full semver archetype id in archetype_details, and AQL should do a full pattern based matching - needs further analysis, goes hand in hand with at-codes pattern matching

• we will need to add a new property to archetype_details to carry on the v2/3 template_id and one new property for the concept (that being the old style of template_id), while the template_id will carry on either the old name or a new name - RM change

  • also a placeholder to store the old template-id from adl1.4 inside a new adl v3 template

• New behaviour for archetype root nodes

  • LOCATABLE.archetype_node_id will contain: at000x.y

  • LOCATABLE.archetype_details.archetype_id will contain full archetype id with namespace and full semver version

  • Consequence: new synactic sugar needs to be for AQL paths so that you still can use paths like

    • SELECT a/items[at0001]/value as analyteResult FROM EHR e CONTAINS COMPOSITION c CONTAINS OBSERVATION o[openEHR-EHR-OBSERVATION.laboratory_test_result.v1] CONTAINS CLUSTER a[openEHR-EHR-CLUSTER.laboratory_test_analyte.v1] WHERE ...

18:30 -

Dinner

Nov 16, 2023

Nedap, Groenlo

07:45

Gather for the bus, riding 50 minutes to Groenlo

todo: @Sebastian Iancu some thoughts to be sorted out / suggestions for agenda:

•  

• conformance testing

• low code / no code / UI

• flat format

• BMM schema / UML / schemas

• strategy SEC

• roadmap specifications

• package system

• bridging gap FHIR

• service models

•  

•  

09:00 - 12:00

ADL2/3

• there will be some assessments that has to be finished, but we should also think about roadmap / milestones / migration path

• agreements on ADL3 WG:

  • @Bostjan Lah will work on writing / managing specifications of ADL v3 (including AOM)

  • WG:

    • @Alex Vidrean will represent EHRBase in the WG

    • @Rong Chen will represent Cambio both on CDS as CDR

    • @Mattijs Kuhlmann will join from Nedap

    • @Sebastian Iancu and @Pablo Pazos reviewers

    • @Sebastian Garde from Ocean

  • @Bostjan Lah: once we know if we can keep at-code, we can evaluate timeframe to migrate tooling and platforms at Better and we can elaborate a more exact roadmap

  • @Pablo Pazos once we have v3 we should deprecate v1.4 and v2; recommend directly v3

  • we will need to contact / check with DIPS as they will be also affected

  • @Pablo Pazos we will need a “central” place for all conversion tooling so that we could all reuse conversion or migration components in our stack

  • we will need to evaluate the impact of referring or using Basic EL vs Advance EL in the AOM2; we should make it easy in ADL3 to choose the “right” or package, or be more relax on using one package of your choice. We need to avoid having to introduce a new breaking change later. It should be clear for AOM/ADL implementers what to do. @Pieter Bos knows more about the potential impact of these issues.

    • we need to gather a list of requirements from EL

    • @Pieter Bos the Basic EL is used and good enough for AOM/ADL2 - no real need or pressure to change it

    • the Decision support WG should look/evaluate the completeness of the Basic EL

    • we consider “parking” Adv EL because it looks like there is no need/path for integrating or implementing to ADL and tooling

    • if we would like to use in the future a “mainstream” alternative, we should facilitate to adopt it in the future so that we don't have to invent our own language

  • @Pablo Pazos introducing ADL3 is also an opportunity to “switch” to other serialization format as the main one. We should consider JSON and YAML. We could then slowly deprecate ODIN in ADL3 so that we remove in ADL4.

    • YAML looks more suitable for what we need, object cross-references (@Erik Sundvall); @Bostjan Lah we should try to convert an archetype to YAML just to see how is looking - we need some experiments.

    • YAML might have issues serializing rules and EL

    • YAML might also have problems with definition and constraints

    • ask @Thomas Beale if he had experiments with YAML & openEHR

  • @Ian McNicoll later on let’s investigate if we could also use FHIR value-sets, nested value-sets - but it should not be a show-stopper for ADL3, but it could be nice if we could do something like that

14:00 - 15:00

@Sidharth Ramesh

REST, SMART

brief reporting on status

• IHE

• -profiling for multi-EHR federation Extracts

• @Erik Sundvall AQL profiling, federated AQL

• ATNA logging for openEHR (@Seref Arikan )

• @Bostjan Lah we already have a XDS metadata cluster archetype, saved in context of composition

• IHE-UK

• profiles can might do well work with us is PIX PDQ (@Pablo Pazos )

• ISO24305 is creating FHIR profiles for ISO13606 RM classes, can be used as a basis for openEHR profiles

• federation impact, MPI

• null flavours (@Sebastian Garde )

15:00 - 16:00

16:15 - 17:15

Bus back to Arnhem

18:30 -

Speakers Dinner