2021-10-13 SEC Meeting, Berlin

Berlin in 2003 (TB)

Place and Date

Chausseestraße 86 | 10115 Berlin (Mitte)

Room: “Work” (https://meeet.de/raum/berlin-mitte/work-arbeitsraum/)

Oct 13, 2021


SEC Physical

SEC Remote

Won’t attend

SEC Physical

SEC Remote

Won’t attend

  • @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


  • Agree Conformance roadmap

  • Roadmap to ADL2 - concrete progress?

Possible Agenda items

Major directions

  • conformance roadmap

  • service architecture roadmap

    • see e.g. CatSalut plan

    • questions:

      • terminology service

      • demographic service approaches

      • ID/access management; RBAC / ABAC etc

      • consent

      • secure EHRs and EHR id / subject id xref service

      • subject proxy service

      • ECA triggers - @Erik Sundvall - have a think about standardised approach to triggers on commit; for notifications, CDS calls etc; in an ECA model: what can be in the Condition? E.g. archetype/template ids, has path = xyz etc; AQL result = xxx;

    • ‘Ideal’ clinical data platform concept

  • ADL2 roadmap

  • tools, resources, open source

Detailed ongoing work

  • ?view Entries & managed lists












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:

@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


@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.


~~~~ L U N C H ~~~~

(We got some mixed bagels provided by the venue)


13:30 - 14:00

REST contd


Admin REST calls, incuding Delete


  • 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


  • 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?






@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



~~~~ caffeine ~~~~



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;

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


~~~~ bier ~~~~



Useful information

-We booked a streaming setup for a hybrid event. Should hopefully allow us to have a high quality remote event

-There is beverages and snacks included

Action items

@Thomas Beale WebTemplate format: issue v1.0 of spec with wt.flat only documented. First draft mid Dec 2021?
TERMINOLOGY: Establish namespace x URI xref mapping to map ‘snomed-ct’ + variations to http://snomed.info etc. Use FHIR list.
@Pieter Bos - modify Archie JSON schema file naming - change version to 2.0 + status = TRIAL; Pieter will generate out per-class files for web, also combined file for development. @Sebastian Iancu check on web rendering etc.
Develop a list of benefits for CDR systems to move to ADL2, versus costs & risks.
AQL: Potentially add Folder-based AQL examples to AQL examples doc.
AGENDA ITEM NEXT SEC CALL: @Seref Arikan Access control in openEHR - ABAC and others