Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
@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
@Bostjan Lah can we use (as a copy) Archie grammar as the official ADL 2 grammar ?
@Seref Arikan Archie should use the (copied) grammar from specs - consider also potential license issues
vote: all in favour
@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
todo: @Sebastian Iancu make sure tickets are there processes correctly on the branch
@Seref Arikan we need a confluence page where we centralize all changes of from ADL 1.4 to 2.4
todo: @Ian McNicoll has a start (see SWOT page)
@Severin Kohler we should have an architecture doc explaining the changes and their reasoning
@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)
@Bostjan Lah we are committed to ADL 2 also with AD
@Seref Arikan it is better to all be committed to 2.4
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 ?
vote: no, we will not carry them. TODO: @Bostjan Lah edit out the line in the specs. Will reconsider for adl3.
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.
agree to localize it to at9000 and above - todo: @Bostjan Lah add it to specs of ADL 2.4
@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 https://openehr.atlassian.net/browse/SPECTERM-30
the group agrees that the notes about at-codes choice as openEHR vendors should go in ADL 2.4 as well as conformance specs
11:00
10 min
Break
80 min
AM 2.4 (ADL2+)
@Ian McNicoll
A few outstanding crucial ADL2 issues...
Nested terms
.opt2 ? Webtemplate2
migrating templateIds
Handling namespaces
id-codes v3 styles
question adding some adl feature to 1.5 so that we can ease migration to 2.4
@Joost Holslag@Seref Arikan we will need ADL2/OPT2 → OPT 1.4 conversion
@Bostjan Lah we have that in AD, we will still going to support it, we might consider opensource part of that conversion code
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
@Joost Holslag the hashes are useful in some situations, it would be better to keep a place to keep the hash; @Sebastian Garde maybe we should just use md5 over the whole file (thus not the canonical hash)
@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
@Joost Holslag we think it is already there in the root; need further investigation todo @Ian McNicoll
RM & BASE
@Sebastian Iancu
not discussed
but there was ad-hoc discussion about demographic virtual values
todo @Severin Kohler will start a WG to work further on this
15 min
REST API WG
@Sebastian Iancu
not discussed
15 min
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.
15:30
15 min
Break
75 min
CDS WG
Try to kick-start WG decision/process support (GDL2/TP etc) @Rong Chen
1h - 2h
BPM+ in FHIR
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,
17:30
Ending
Jun 7, 2024
09:00
5 min
Opening & Agenda
WG: virtual demographic archetype
Severin, Sebastian I, Ian, Seref, Chunlan, Rong, Bostjan, Jake(?), Diego
2-3 meetings; review usecase
10 min
Terminology v3.1.0
@Sebastian Iancu
not discussed
60 min
Terminology
@Severin Kohler@Ian McNicoll
simplifying terminology (for ADL2 mainly)
also terminology binding mappings @Severin Kohler
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
60 min
interop FHIR+OMOP
@Severin Kohler
structural mapping
@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
13:00
45 min
Lunch
13:45
90 min
openEHR & HL7
@rachel dunscombe
FHIR / HL7 collaboration plan & impact
SEC: produce a doc on what would be our vision
15:15
15 min
Break
15:30
90 min
SEC general matters
todo: review what should be deprecated
strategical planning of spec (long term)
UML > BMM > asciidoctor
consensus from present members to initiate procedure on Retire following specs:
CNF tests SUT
SM entirely
PROC entirely, overview merges into CDS
RM: EHR extract
LANG: P_BMM (our move it to ITS), EL
needs review
CNF
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
menu too complex, too much text on main page
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
@Sebastian Iancu consider @Ian McNicoll suggestion to label tickets based on action that has to be takken on the ticket
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’
vote all in favor
Propose: move all amendment sections of specs to be moved by the end of docs