2022-10-17 SEC Call notes

5 min

Opening

USEFUL Jira RESOURCE: CRs I have not accepted.

SEC Jira board.

15 min

openEHR platform release management.

@Pablo Pazos

@Thomas Beale

Currently we release at a Component level, e.g. RM 1.1.0, AM 2.2.0 etc. We don’t currently have a full ‘platform release’ mechanism. To take care of e.g. RM 1.1.0 needs at least BASE 1.0.4 or similar.

NB: general idea of the components in openEHR was to be loosely coupled, and have limited version inter-dependency.

• @Thomas Beale : possibly implementable with Github submodules. But how to define the platform release baselines? [But: really needed?]

• @Sebastian Iancu really needed? If can be avoided, … better approach is per-component, dependencies list, i.e. min; other UC: AQL could rely on a min RM release, to allow tags & folders, which are new/modified

• @Seref Arikan take a conformance testing point of view - what works with what?

• AGREEMENT: don’t require whole-of-openEHR ; need a limited dependency list/tracking per version of each component; ideally shown on the specs website on release table view.

  • also add in subsection to Preface of all? some specs that have dependencies.

15 min

Specification lifecycle management

@Pablo Pazos

We don’t currently mark specs as Obsolete / deprecated etc, although we do have guidelines for this.

The old PDF specs probably should be taken offline? We can’t regenerate them, so can’t easily mark them as deprecated within the docs.

When do we deprecate RM, AM etc specs? Probably all pre-1.0.2 RM should be deprecated.

15 min

JSON schema update

@Pablo Pazos

Working on 2 versions of schemas -

• canonical one

• relaxed one for API

Generated various RM versions.

Question on how XXX_REF classes are represented in JSON schema.

Based on JSON schema errors/ issues, BMMs might have issues and/or Archie BMM → JSON-schema generator.

@Sebastian Iancu what variant of JSON schema to support in OpenAPI, versus in back-end CDR? What level of JSON schema spec supported for (external) payload spec, by OpenAPI? Also - question of ‘relaxed’ mode schema.

Could defined relaxed form of RM in SM, and make BMM of that - this would then be a source for JSON schema that an be referenced from OpenAPI.

30 min

REST API update

@Seref Arikan (Personal)

@Sebastian Iancu

OpenAPI Strategy

• https://discourse.openehr.org/t/open-api-strategy/2668

• API Blueprint => OpenApi

Overview for REST API todos - for Release 1.1.0 (or 2.0.0)

Progress:

• @Seref Arikan - OpenAPI mature enough yet? BUT: could OpenAPI function as BMM alternative? For data only, possibly.

• @Sebastian Iancu - still more mainstream as a spec technology (APIB probably dying), even if code generation not quite working (particularly polymorphism)

  • Note: FHIR maintains 2 XSDs one for code-gen, one for spec-representation

• @Ian McNicoll - don’t bother with canonical RM complexities and support only web template formats? (TB: probably true for 85% of devs).

  • would help a lot of have web template form represented directly in OpenAPI, with leaf constraints rules built-in to spec

• @Thomas Beale arguably 3 levels of representation - maybe only last 2 relevant for APIs:

  • full canonical RM etc

  • simplified RM

  • web template formats

• @Erik Sundvall get the clinical content examples better aligned across ITS docs

Issues:

• relationship between REST API release and releases of payload, i.e. RM, AM etc.

Outstanding topics:

Agenda items: