Page Comparison

Meta

5 min

Opening

USEFUL Jira RESOURCE: CRs I have not accepted.

SEC Jira board.

5 min

New website - see SEC and other areas.

Thomas Beale

Main Agenda

15 min

AQL

Seref Arikan (Personal)

Picking up data from specialised archetypes.

See latter part of Discourse discussion.

Seref Arikan (Personal) - detailed analysis of AQL query results across system boundaries - pick up again next call.

• ok to support archetype polymorphism in an AQL engine - this is correct

• BUT there are edge cases - specialised data can end up in a context where it breaks things, e.g. update of that data in a system that doesn't a priori have templates based on that specialised archetype

• PROBLEM is Composition-level fetch via AQL - because client won’t see specfic template id and therefore won’t know that more specific (narrower) constraints need to be respected.

• REMEDY: make it explicit in the query that direct instances or direct instances + instances of child types - e.g. via C[? extends 'parent_archetypeid']

• [TB] Question: what rules are servers implementing w.r.t respect to matching root archetype ids below top Composition structure.

• [PB] - can require specific template id in WHERE clause - need to do this to make sure you are getting the right templates.

10 min(?)

Computable references

Seref Arikan (Personal)

How to improve the referencing mechanism(s) of openEHR.

Relevant discussion in discourse.

Index compositions (of sorts) are used in practice and is likely to be required even more.

Ideally we should identify the requirements for these, come up with a roadmap for specifying them and discuss in details. Example: how to avoid dangling references (both at creation and at updates)? What would it mean for implementations. Benefits/Costs.

Optional Can-of-worms aspect: can we use this to improve RM based mock-demographic implementations out there? by adding more semantics to references? In the same way graphs having well typed edges/relations.

MAIN Q: are openEHR implems checking link targets existing (recursively!) before commit? Commit should fail if any links not resolvable.

Question: granularity of link targets? What about targets of more specialised RM types?

Pieter Bos : similar logic to DB cascade delete

Diego Bosca : FHIR

FHIR references page: “References SHALL be a reference to an actual FHIR resource, and SHALL be resolvable (given that access control works, there is no temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL (see below) and looking it up in a local registry/repository”

Q: access control may block ref being resolved, even if it is there.

Archetype ref constraint: possibly should be able to point to target of type ‘Patient’ in a on-openEHR server.

15 min

REST Api

Seref Arikan (Personal)

OpenAPI Strategy

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

• API Blueprint => OpenApi

• Release 2.0 (breaking changes) ?

• Core team + goals ?

Overview for REST API 1.1.0 work to be done

Update:

• meeting 1: Seref Arikan (Personal) / Pablo Pazos / Sebastian Iancu - how to set up Stoplight

• meeting 2: decided on OpenAPI 3.0 rather than OpenAPI 3.1 - latter is quite immature

• Sebastian Iancu did a APIB blueprint → OpenAPI initial forward generation - team will go manual now - Git sandbox repo.

• See the wiki of the Github repo for status updates/goals etc.

15 min

New Registry model

Thomas Beale

Define new model? Back-port features to demographics

Tips and Tricks

Hackers' Corner

Next SEC call

Outstanding topics:

Agenda items: