2023-08-21 SEC Call notes

15 min

Opening

@Sebastian Iancu

USEFUL Jira RESOURCE: CRs I have not accepted.

SEC Jira board.

@Joost Holslag (Deactivated) @Sebastian Iancu@Pieter Bos

SEC Face2face meeting Netherlands 15-16 Nov 2023, followed by an openEHR conference on 17th Nov 2023

Conference with parallel tracks for policy and devs.

SEC Meeting 15-16 Nov at Nedap

CPB Meeting on 16 Nov

Mini-conf with Nedap & openEHR for 1-2h at Nedap on 16 Nov

Conference on 17 Nov at Burger Zoo Arnhem, 3 parallel tracks

5 min

WGs implementation

@Sebastian Iancu

Status update

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

We should get it started!

25 min

Priority 1 - ADL2 adoption

@Pieter Bos

Status update

Related background material:

• https://openehr.atlassian.net/wiki/spaces/ADL/pages/2148630574

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

@Jelte Zeilstra present on behalf of Nedap for ADL2 migration

@Joost Holslag strategy to deal with data, that allows accessing both variant (ADL2 and ADL1.4 based data), via two different endpoint styles, containing a version specifier in the url

@Bostjan Lah not very enthusiastic because this is not solving yet the problem; we should only deal with the id-codes introduced by ADL2, that is the main problem

@Alex Vidrean also not very enthusiastic, having two different endpoints - but cannot comment on difference ADL1.4 ADL2

@Rong Chen it is not not only about REST but also about the downstream apps, with all the dependent paths; we should keep the complexity on one level (CDR) and not spread the solution also on apps

@Erik Sundvall …

@Joost Holslag there is a negligible risk for ADL1.4 client apps to work with ADL2 data to produce user impacting errors. Because the paths are so different ('id' vs ‘at’) that they will fail quickly.

There is a general consensus toward going to a common-ADL (ADL3), but the migration cannot be gradual (i.e. supporting just a few features from the whole set)

@Pablo Pazos for moving all ADL 1.4 and ADL 2 to a new convergent ADL 3 spec, we would need:

1. specify a migration path for data, archetypes and templates (how to do mappings to maintain meaning ADL 1.4/ADL 2 => ADL 3),

2. implementation guides of path depending functionalities, like how will data validation work with archetypes that have specializations (node_ids might change in the specialized archetype like specified in ADL2), including pseudo-code so there is no space for interpretation by implementers, (other areas that might need guides are: GDL/rules, queries, GUI/form generators, etc),

3. deprecation path: ADL 1.4 and ADL 2 should be deprecated, propose an end of life time, like 2 years, for implementers to have time to migrate to ADL 3, then archive the specs as “obsolete”.

@Sidharth Ramesh is going to be hard for apps to deal with partial implementations of ADL and be aware of all complexity caused by mixture of ADL 1.4 / ADL2

15 min

Priority 2 - Conformance testing

@Alex Vidrean

Status update

Skipped

15 min

REST API

@Sebastian Iancu

Update on work with @Sidharth Ramesh :

• SMART-app-launch -

• Eventing -

Starting the WG

@Sidharth Ramesh , @Jake Smolka @Sebastian Iancu

We should discuss about eventing and the feedback this on the first meeting of the REST WG. @Sebastian Iancu will schedule the meeting

@Sebastian Iancu and @Sidharth Ramesh will publish on SEC discourse the first SMART draft. Further details and feedback will be discussed on same WG meeting.

@Sebastian Iancu

• RM 1.2.0

• Federation

Erik Vermeulen (EY) wants to propose a new specification about an openEHR Federation layer, based on EY Connected-Health.

SEC agrees reading a draft, then it will decide if it should be accepted under openEHR specification (and where). SEC invites also Erik V to present this draft in one of the next SEC meeting.