2022-06-13 SEC Call notes
Date
Jun 13, 2022
Call Link
Participants
Thomas Beale
Sebastian Iancu
Diego Boscá Tomás
Bjørn Næss
Seref Arikan (Personal)
Matija Polajnar
Erik Sundvall
Pieter Bos
Rong Chen
Former user (Deleted)
Goals
previous meeting:
Discussion topics
| Item | Presenter | Notes |
|---|---|---|---|
Meta | |||
5 min | Opening |
| USEFUL Jira RESOURCE: CRs I have not accepted. |
10 min | SEC governance update. | Thomas Beale Sebastian Iancu | Co-chair election result. Agree to default result (no vote; announce on Discourse) |
10 min | SEC representation challenge, meeting time |
| Review from last call Erik: rotation might be tricky; Expand experts list (possibly significantly) Voting formally taken care of by SEC core member, but we assume advice taken privately from each company experts. |
| NL event - report | Sebastian Iancu | 45 attendees from NL; good mix of devs, policy-makers (including ministry); FHIR experts; Some recordings available (Sebastian Iancu ) |
Main Agenda | |||
|
|
|
|
| Finalising design approach to ‘archived’ lifecycle state: https://openehr.atlassian.net/browse/SPECRM-107 |
| TB: propose we call this ‘inactive’ rather than ‘obsolete’. |
| Tags - currently in review, but is it complete? |
|
|
| ISM_TRANSITION doesn’t inherit from LOCATABLE
| Thomas Beale | Classes that ‘should’ inherit from LOCATABLE but don’t: ISM_TRANSITION, PARTICIPATION, ?EVENT_CONTEXT. Allocate to openEHR RM 2.x Archetypes? and templates should contain indicator to major version of RM Migration guides, algorithms etc for data / model |
| How to connect ACTIONs to ACTIVITYs | Pablo Pazos , Birger Haarbrandt | RM 2.x for now |
| Upgraded / new demographics / registry model. | Sebastian Iancu | RM 1.3.0 for now |
| Use UML enumeration? | Pablo Pazos |
|
15 min | AQL querying - 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. |
Tips and Tricks | |||
|
|
|
|
Hackers' Corner | |||
|
|
|
|
Next SEC call | |||
| Outstanding topics: Agenda items:
| ||
Notes
Action items
ALL - nominate in-house experts from your org for addition to SEC Expert Panel
Comments
Sorry - answering now!! I support the need for an inactive state but I’m not sure it is clear what the default query behaviour should be, which is partly why I’m not all that keen to make this an RM attribute. I’m not sure there is a straight find/not find query return - it will very much depend on the overall intent and architecture. If it cannot be found by AQL, how do we find it!! Or is the idea that only an explicit AQL lifecyle_state = ‘inactive' would return it (as we do for ‘incomplete’.
I definitely think that inactive works better than obsolete. As an example we might have a situation where a patient needs recurrent hip surgery, with a care plan /journey for each 'episode’. The previous plan/journey would definitely be of interest but you would not want to mix it up with an active record.
My recommendation: default query behaviour should be ‘do not return unless explicitly requested by a lifecycle = inactive clause’. If we do not have that, I'm struggling to see the utility TBH.
So I agree with Joost Holslag (I think!).
In Ocean, what we are doing is to return the active by default, and allow lifecycle_state parameters, e.g. inactive, or {“active“, “inactive“}
Re the inactive state: it’s blocked by a decision default return by AQL, I’m unable to get
Ian McNicoll and 
Heather Leslie and others to answer. 
Bjørn Næss is fine with either as long as it’s well specified.
My opinion is to not to return inactive data by default, only with an ‘including inactive’ param. Because it’s intended to contain data that is no longer current.