| | | | | |
|---|
Jun 6, 2024 |
| | Opening & Agenda | ALL | SEC Jira board. | |
| | Co-chair election | ALL | | 3 nominations for co-chair: Bostjan L, Rong C, Sebastian I The SEC has no objection in relation with nominees, and agreed that they will be co-chairs for the next term up to June 2026. Discussion about: rotating co-chair task responsibilities - this needs to be further explored continuity of co-chairs croup vs SEC member @Severin Kohler needs onboarding docs for newcomers, process description @Bostjan Lah we need to formerly ask inactive members to quite if they want so or delegate other persons vote for @Severin Kohler to become a SEC member - all members agrees suggestion for two candidates for SEC expert: Borut Jures, Renaud Subigre
|
| | AM 2.4 (ADL2+) | @Bostjan Lah | Review | @Bostjan Lah We are at the point where we could publish; we had extensive review on the wording a branch AD will have support for ADL 2.4 in June/July Nedap is working hard on making support for ADL 2.4 grammar in Archie @Sebastian Garde migration for CKM archetypes is a major work item ; we will need first to agree on template formalism before moving to template @Severin Kohler where/what is the change ticket for ADL 2.4 @Seref Arikan we need a confluence page where we centralize all changes of from ADL 1.4 to 2.4 @Ian McNicoll we will need to assess if there is a need to backport some of the ADL2x changes that have no impact on CDRs to ADL1.4 (as 1.5) reconfirm that at-codes are the future for openEHR, we will have to make it clear in the specs so new openEHR RM implementers will implement at codes . There's a desire to deprecate id coding. but it will be left to decide for a next adl version. adl2.4 will support both at and ID coding. @Joost Holslag will we carry on id codes in adl 2 archetypes ? agree to start from at0000, keep it the same in ADL1.4; TODO @Bostjan Lah make it clear in specs From @Ian McNicoll 's list, only the numbering scheme for at codes (first point) needs to be specified. The other points can be solved after adl2.4 vote. @Joost Holslag we need to discuss common expected formats (op2/adls/json/yaml) between AD, CKM and CDR. But only after publishing adl2.4. AOM changes are not necessary because we decided that we don’t need to carry id-codes review implications of latest BASE required by AOM2 and propose changes if needed so that it can be correctly used by ADL2.4 see for example comments on SPECTERM-30: Add codes for RESOURCE_DESCRIPTION.lifecycle_stateAnalysis the group agrees that the notes about at-codes choice as openEHR vendors should go in ADL 2.4 as well as conformance specs
|
| | Break | | |
| | AM 2.4 (ADL2+) | @Ian McNicoll | A few outstanding crucial ADL2 issues... |
| | Lunch Break | | | |
| | ADL 2.4 | | | @Joost Holslag @Seref Arikan we will need ADL2/OPT2 → OPT 1.4 conversion source formalism for template, something as alternative to .oet files (from v1.4 world) .adlt file could be a an alternative, based on openEHR Template specs (AOM2) (.adls is the archetype version of the …)
re: decision to keep the MD5 hash (optional field) in archetypes, but don't use it as identifier of the archetype @Severin Kohler the annotations is a inconsistently specified; it should be free to use annotations but recommendation is to use properly on the question of keeping historical version of archetypes in CKM, we will keep the history (in ADL1.4) @Ian McNicoll we should have a new attribute to capture the template title
|
| | RM & BASE | @Sebastian Iancu | | not discussed but there was ad-hoc discussion about demographic virtual values |
| | REST API WG | @Sebastian Iancu | | not discussed |
| | Federation WG, Authorization | @Joost Holslag | | do we have an agreement to consider the entry the lowest level? @Matija Polajnar we limit on the composition level yes, agreement authorisation scope should be no smaller than an entry. Unsolved: how to handle conflicts between entry level and composition level acces policies.
@Seref Arikan we may disagree with legal/social requirements, but we should be able to facilitate ACL policies @Sebastian Iancu @Seref Arikan UK and Turkey have broad acces policy by default, unless specific data (model) is marked as sensitive. Warns against defining fine grained access policies, due to complexities. @Joost Holslag NL law requires a no acces policy by default @Severin Kohler @Joost Holslag political realities require decentralising CDRs @Joost Holslag There’s a requirement to blind specific elements in a specific composition for a specific user/role. E.g. patient has access to all data in the EHR, except for specific information that could be harmful for the patient to know, e.g. psychiatric patients. This requires blinding on the element level by the commiter of the information. And shouldn't be done at the model/archetype level as not to conflict with the entry as unit of information rule.
|
| | Break | | | |
| | CDS WG | | | consider deprecating/parking TP, try to shrink more of the specs/components, reduce complexity @Ian McNicoll check if BPM+ might be something to be adopted @Seref Arikan can we adopt e.g. typescript base scripting? check ‘wasi’ @Ian McNicoll we should have a really basic way of expressing rules in archetypes, the way Nedap is doing; rules should “stay” with archetype WG: Rong, Seref, Ian, Matija,
|
| Ending |
Jun 7, 2024 |
| | Opening & Agenda | | | WG: virtual demographic archetype Severin, Sebastian I, Ian, Seref, Chunlan, Rong, Bostjan, Jake(?), Diego 2-3 meetings; review usecase
|
| | Terminology v3.1.0 | @Sebastian Iancu | | not discussed |
| | Terminology | @Severin Kohler @Ian McNicoll | | Severin presents issues he find using term mapping on model and data side Ian presents issues with terminology bindings, comparison with valuesets question: what if we would use or express archetype ontologies (local at-codes) as FHIR values sets inside archetypes ? AQL syntactic sugar for querying across mappings and defining_code @Ian McNicoll let's take this as a question for HL7 collaboration project context should we consider allowing mixed valuesets including null_flavour codes? DV_TEXT/DV_CODED_TEXT => why not use CodeableConcept @Bostjan Lah why not add a new type DV_CODEABLE_TEXT, which looks like DV_CODED_TEXT but the code is optional, similar to FHIR CodeableConcept ? @Seref Arikan good idea, but what would be the impact on existing CDR data
|
| | interop FHIR+OMOP | @Severin Kohler | | @Severin Kohler presents proposal to have common mapping language based on FHIR connect specifications FHIR and OMOCL mappings are going to be supported by CKM on a mapping tab @Severin Kohler and @Diego Bosca takes indicative's on taking this further and formalize it, perhaps propose a WG
|
| | Lunch | | | |
| | openEHR & HL7 | @rachel dunscombe | | |
| | Break | | | |
| | SEC general matters | | | needs review We should remake the main landing page of specifications and menu: todo: @Sebastian Iancu hide all D specs on release baseline todo: @Sebastian Iancu @Bostjan Lah ask feedback in our companies and on discourse about how the landing page should look like, how to reorganize the way we present specs todo: @Sebastian Iancu generate new website (test)
Jira: continue with jira-adoption; if a tickwet is not assigned to a person we will have to add a label so that we need to discuss it in the group We need to review the ToR doc so that: members that are de facto inactive for a specific period of time (6months) should be asked to resign their role or propose a replacement, or to join the SEC expert group add requirements that members should be present at least twice a year on SEC meetings todo: @Rong Chen execute this
Propose: url of stable specs should be now ‘latest’, and the dev-baseline goes to ‘development’ Propose: move all amendment sections of specs to be moved by the end of docs
|
| | | | | not discussed |
| Ending |