path refers to AQL path (need to remove mentioning RM paths); positional predicate is not considered to be safe for json serialization/deserialization
add invariant that if you use path, the versioned_object should be used
improving text because is not clear what is the use case: searching, but also labelling nodes or compositions (Erik Sundvall)
name/coding might be need to transport semantic, key might be not very clear → but suggestion is to use folders for more complex use case where you want to code the tags
“looks like annotations”
atomic way adding tags to composition in a contribution
offtopic: contribution is transaction unit
target_path in REST API uri is nasty; it might need to have an id to uniquely identify in the management operations
that might create the premise of having an dedicated api uri - becoming a resource
Pieter Bos we should check also FHIR tags, to see how is dealing with coding
add 0..1codeCODE_PHRASE or string - see DV_QUANTITY , but keep it simple
see EhrScape yaml
SYSTEM
still ok adding; Sebastian Iancu should work on it and propose it to SEC
EPISODE
Ocean uses workflow_id to “group” compositions as part of an Episode
the consensus is that is too early to have such a type, rather use FOLDERs based on a specific (recommended) archetype, and add an implementation guide about use of this archetype+folder, potentially describe use of tags to implement episode context
…thus no new type
use of episode in a contribution is complex and we will need to define the logic of atomic contribution
[Addition by Erik Sundvall: CONTRIBUTIONs have been implemented as a transactions by all vendors present at this SEC meeting, so that is not the complex thing, but might (according to Seref Arikan's previous discussions with Thomas Beale) need to be clarified in the spec anyway. A remaining complexity is how you link/cross-reference between several different new objects in the same CONTRIBUTION API call before the server has given them their permanent IDs. One way of doing that is that the application calling the API assigns temporary strings as IDs for the new objects and uses the same strings in references from other objects sent in the same CONTRIBUTION]
WG episode with clinical modeling to further identify the IG
group is wondering if we should drop the id-coding
apparently no impact on ckm / modeling process
there might be an impact on Nedap’s models an applications
Erik Sundvall adding alias keys to nodes to AQL paths, and id-code could be also a key - this should be supported by RM also
Bostjan Lah maybe we could use mapping attribute on locatable.name.mappings instead of adding new attribute in RM
Pieter Bos Nedap will check how big of the problem is overlapping id-code with at-code; check if introducing an extra key will solve the overlapping issue
Pieter Bos we should add to adl2 specs a deprecated warning to not use overlapping on numeric number
Sebastian Garde once we are on ADL3 we might not support ADL2 to avoid issues
Pieter Bos we should do the conversion of “all” archetypes on a single point so that we have a unique reliable id-codes
add syntactic sugar for adl paths items[code = 'SNOMED-CT::123456'] like items[code = 'local::at001'] where the code is the shortcut to mappings
Erik Sundvall added afterwards: The syntactic sugar design likely needs some more consideration. Is it things like items[name/mapping/target='SNOMED-CT::1234567'] or items[name/mapping/target/code_string='SNOMED-CT::1234567']that was suggested to become something like items[code='SNOMED-CT::1234567'] ? If so it might be confused with DV_CODED_TEXT.defining_code (which is archetype_node_id: another CODE_PHRASE).
2023-12-11 addition at/after SEC meeting: for the “human readable keys” discussed (as optional extra alternative to at/id codes) we should likely have some shorter syntactic sugar like items[#my_fancy_readable_code] or items[#'my_fancy_readable_code'] or items[@my_fancy_readable_code] or whatever
don’t need to do anything particular change after migration to ALD3 if you have archetype_node_id on v1 style, the dashed name we’ll not have any meaning
for CDRs implementing ADL v3, store the full semver archetype id in archetype_details, and AQL should do a full pattern based matching - needs further analysis, goes hand in hand with at-codes pattern matching
we will need to add a new property to archetype_details to carry on the v2/3 template_id and one new property for the concept (that being the old style of template_id), while the template_id will carry on either the old name or a new name - RM change
also a placeholder to store the old template-id from adl1.4 inside a new adl v3 template
New behaviour for archetype root nodes
LOCATABLE.archetype_node_id will contain: at000x.y
LOCATABLE.archetype_details.archetype_id will contain full archetype id with namespace and full semver version
Consequence: new synactic sugar needs to be for AQL paths so that you still can use paths like
Code Block
SELECT
a/items[at0001]/value as analyteResult
FROM EHR e
CONTAINS COMPOSITION c
CONTAINS OBSERVATION o[openEHR-EHR-OBSERVATION.laboratory_test_result.v1]
CONTAINS CLUSTER a[openEHR-EHR-CLUSTER.laboratory_test_analyte.v1]
WHERE ...
=== nothing / hotel ===
18:30 -
Dinner
June 7 2023
Nedap, Groenlo
07:45
Gather for the bus, riding 50 minutes to Groenlo
todo: Sebastian Iancu some thoughts to be sorted out / suggestions for agenda:
conformance testing
low code / no code / UI
flat format
BMM schema / UML / schemas
strategy SEC
roadmap specifications
package system
bridging gap FHIR
service models
09:00 - 12:00
ADL2/3
there will be some assessments that has to be finished, but we should also think about roadmap / milestones / migration path
agreements on ADL3 WG:
Bostjan Lah will work on writing / managing specifications of ADL v3 (including AOM)
Bostjan Lah: once we know if we can keep at-code, we can evaluate timeframe to migrate tooling and platforms at Better and we can elaborate a more exact roadmap
Pablo Pazos once we have v3 we should deprecate v1.4 and v2; recommend directly v3
we will need to contact / check with DIPS as they will be also affected
Pablo Pazos we will need a “central” place for all conversion tooling so that we could all reuse conversion or migration components in our stack
we will need to evaluate the impact of referring or using Basic EL vs Advance EL in the AOM2; we should make it easy in ADL3 to choose the “right” or package, or be more relax on using one package of your choice. We need to avoid having to introduce a new breaking change later. It should be clear for AOM/ADL implementers what to do. Pieter Bos knows more about the potential impact of these issues.
we need to gather a list of requirements from EL
Pieter Bos the Basic EL is used and good enough for AOM/ADL2 - no real need or pressure to change it
the Decision support WG should look/evaluate the completeness of the Basic EL
we consider “parking” Adv EL because it looks like there is no need/path for integrating or implementing to ADL and tooling
if we would like to use in the future a “mainstream” alternative, we should facilitate to adopt it in the future so that we don't have to invent our own language
Pablo Pazos introducing ADL3 is also an opportunity to “switch” to other serialization format as the main one. We should consider JSON and YAML. We could then slowly deprecate ODIN in ADL3 so that we remove in ADL4.
YAML looks more suitable for what we need, object cross-references (Erik Sundvall); Bostjan Lah we should try to convert an archetype to YAML just to see how is looking - we need some experiments.
YAML might have issues serializing rules and EL
YAML might also have problems with definition and constraints
ask Thomas Beale if he had experiments with YAML & openEHR
Ian McNicoll later on let’s investigate if we could also use FHIR value-sets, nested value-sets - but it should not be a show-stopper for ADL3, but it could be nice if we could do something like that