2021-10-13 SEC Meeting, Berlin

• @Thomas Beale

• @Diego Bosca

• @Ian McNicoll

• @Sebastian Garde

• @Bjørn Næss

• @Birger Haarbrandt

• @Jake Smolka

• @Pieter Bos

• @Pablo Pazos

• @Erik Sundvall

• @Seref Arikan

• @Matija Polajnar

• @Sebastian Iancu

• @Shinji Kobayashi

09:00 - 09:30

Agenda setting

09:45 - 10:45

JSON WT Flat format

• Progress on flat JSON / simplified data formats (draft spec)

  • @Erik Sundvall Question: ensure (the widely used) FLAT format that is based on the same path notation as Better “web templates” uses , gets well documented; Can we assume this (Better-based) format is what application/openehr.wt.flat+json refers to in the openEHR REST spec?

  • Answer: YES

@Erik Sundvall : should we name it webtemplate instead of ehrscape in the spec?

@Birger Haarbrandt : ethercis format is not used

Flat and WebTemplate implementation in openEHR SDK: https://github.com/ehrbase/openEHR_SDK

@Matija Polajnar : Better published on github web-template implementation and unit tests

Group: initial rewrite of SDF spec:

• initially spec the ‘wt.flat’ format - use above link Kotlin source code. (Note that the code is not always mapping all attributes, e.g. missing “precision” https://github.com/better-care/web-template/blob/master/src/main/kotlin/care/better/platform/web/template/converter/flat/mapper/DvQuantityToFlatMapper.kt )

• Q: allow mixed flat (paths) and sparse JSON? @Sebastian Iancu mixing dangerous? @Birger Haarbrandt - hybrid format in EhrScape?

@Ian McNicoll potential need to escape out of flat format - use raw canonical within JSON flat. NEED EXAMPLE

Check with Solit-clouds on their implementation of this.

Include links to Better OS code, EhrBase openEHR SDK(?) and also Archie (near future) flat format generation.

• @Ian McNicoll : consider whether/when/how we allow URIs in compact form of Terminology_term; question of what are reliable URIs - FHIR covers only some.

• @Pieter Bos : need for conversion from/to URIs and namespace names (old style)

see list on https://www.hl7.org/fhir/terminologies-systems.html

Document in WTF spec?

ADL2 - currently only URIs in bindings?

11:00 - 11:15 ~~~~ caffeine ~~~~

11:15 - 11:30

@Pieter Bos

@Sebastian Iancu

• JSON schema

Status: Code24 version not completely validating; Archie has a JSON-schema machine generated from RM BMM files. Archie version addresses the polymorphic question.

@Sebastian Iancu - schema naming - need to follow this URL structure - https://specifications.openehr.org/releases/ITS-JSON/latest/components/RM/Release-1.1.0/Data_types

11:30 - 12:45

REST

@Sebastian Iancu

• REST API - directions / plans ; review current CRs - headers question (@Ian McNicoll , @Erik Sundvall)

  • @Sebastian Iancu - status report; integrate changes from RM 1.1.0; when demographics can be added in?

  • @Ian McNicoll - some implem differences found by testing of Better / EhrBase / DIPS

  • @Thomas Beale - need to add in minimal Admin calls for conformance testing e.g. deletions;

  • @Ian McNicoll - make versions easier to handle e.g. how do I change the lifecycle state on an Composition; give me all prev versions; other ‘easier’ utility calls?

• Skipped discussion - already answered by Matja below

  • Question from @Erik Sundvall - do we need a standardised means of passing in e.g. JS script to do ‘data shaping’ / format conversion e.g. JSON → HTML / server side reduction etc; consider like Github ‘hooks’;

  • Answer from@Matija Polajnar : Better ‘javascript views’; can do this currently, e.g. run multiple AQL requests / processing pipeline; Better is getting rid of JS approach due to server resource overload though → this is not a good direction

  • Shared conclusion do not add to spec

@Sebastian Iancu - EHR_ACCESS & ACCESS_CONTROL_SETTINGS. Implement ‘/ehr_access' dedicated REST end-point; in REST return empty JSON '{}’ ?or locally available ACL object. May need controlled visibility.

Do we support definitions API upload of archetypes? Probably useful eventually but not a priority now.

Support terminology value sets in REST API? → for now, now; stick to direct use of FHIR terminology services.

@Ian McNicoll - should discontinue openEHR demographics model.

@Sebastian Iancu - want to improve implementation and extend to REST API

@Seref Arikan - used in Ocean (might be phased out)

@Thomas Beale - if further development, consider Accountability changes.

@Matija Polajnar - not intending to support demographics. Conformance: can include demographics but as optional component.

@Erik Sundvall - problem of patient data creep into EHR

@Thomas Beale - professional demographics requirements getting more complex and getting toward demographic model structure? Discourse discussion.

@Seref Arikan allow different categories of spec - some more industry-led; treat demographics like this.

@Erik Sundvall - need to have innovative specs to push the boundary

Idea to investigate: mark specs as being in certain product categories; could then filter in specifications main page according to product profile keywords.

@Ian McNicoll and @Bjørn Næss - make REST APIs for e.g. demographics and Task Planning etc a separate spec. Need to focus time better, also not create dependencies between e.g. EHR and demographics or TP.

@Erik Sundvall - suggest making separate initially, then integrate.

13:30 - 14:00

REST contd

Admin REST calls, incuding Delete

• EhrBase DELETE calls

• Merge, demerge but later on

Definitions

• would be good to deprecate a template - retains for use with older data, but can’t use in future

• also need to be able to remove all templates for testing

EHR export / import functions - GDPR requirement for export (i.e. patient requests own EHRs). - EHR export needs OPTs to be exported out. @Bjørn Næss national archive example. Potential need to be able to annotate post-export data. Will need AQL to do any kind of filtering.

What is dump format - JSON; treat zip etc as second phase.

System log: Discussion needed on semantics of what might need to be stored in e.g. ATNA log. REST endpoint(s) for audit log access needed, but not in this version; possibly treat as own API.

Check with @Rong Chen re: CDS hooks in REST API.

14:30 - 15:45

Moving openEHR to ADL2

• CKM issues; 1.4 → 2 conversion issues; Archie has slowly fixed various ‘small’ conversion problems; now quite reliable. OPT 1.4 → 2 conversion still experimental in Archie, not built into CKM yet.

• discuss OPT2; including concrete formats - XML & JSON formats - specify how to create an OPT from source form - flattening logic

• establish scope on value set handling; nested value value sets; asserting relationships;

Work items

• incremental Archie work

• CKM changes

• potentially agree on ADL3 format with ODIN replaced by JSON / YAML etc.

• questions of terminology ids - allow URIs and namespaces

• retain OPT14 generation

• question of converting AQL

Design innovations of ADL2

Backward compatible code rules

ADL1.4-related problems and errors

ADL 1.4 migration page

@Seref Arikan (and others) - what is the is the list of benefits for CDR systems to move to ADL2.

16:00 - 17:00

Conformance roadmap

• Discourse

TB, PP, BH

• Pablo’s overview

• product scope

• conformance testing as a service;

• technology: Robot v cucumber; - alternative tech stacks;

• faking conformance due to all test cases being online;

• test case / data synthesisers;

• AQL conformance - what approach?

FINAL WRAP UP

@Sebastian Iancu offer to host SEC @ Alkmaar e.g. end Jan / start Feb, else end March.

THANKS to Vita for enabling hosting !!!!

Ian’s list - terminology, querying, …

@Ian McNicoll

• AQL link following

next RM release CRs

@Sebastian Iancu

: https://specifications.openehr.org/releases/RM/crs

TERM: @Sebastian Iancu just checking if agree on SPECPR-367

next steps AQL

• @Seref Arikan : one vendors group AQL call prior to SEC meeting;

  • initial AQL roadmap;

  • work out scope - what’s in 2.0?

    • Formalised semantics; @Seref Arikan blog posts; permutations

    • what breaks?

    • demographics; @Sebastian Iancu some thoughts here.

    • joins and unions?

    • terminology resolution?

  • IDEALLY: get vendor statements of what permutation handling looks like today (e.g sets v bags) - work from @Seref Arikan teasers as basis for agreeing on common / ?correct behaviours

  • legal issues? in AQL over populations - danger is AQL is a backdoor; need a better privacy model;

  • ABAC service from Better is now open source; need to align access control for EHR with AQL semantics

  • GOAL: obtain feedback from vendors on current

  • Heath Frankel provided feedback as comments in these posts:
    https://serefarikan.com/2021/06/19/archetype-query-language-the-confusing-bits/
    https://serefarikan.com/2021/06/29/archetype-query-language-the-confusing-bits-ii/

@Erik Sundvall AQL on FOLDERs? - EhrBase and others - needs to be in AQL spec.