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 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)
Pieter Bos resigning from SEC, follow up from Nedap is Matijs - no objection from SEC members to accept him as new member.
9:45 - 10:30
@Sebastian Iancu
Jira Board
10:30 - 11:30
@Sebastian Iancu
RM 1.2.0 work, tickets, etc
TAGS
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
need to check with EhrScape API - todo @Erik Sundvall@Sebastian Iancu
@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
constraining links (@Joost Holslag )
constrain mappings (@Ian McNicoll) on templates
@Joost Holslag this might be possible in adl2
AQL should investigate adding demographic flavored functions like age(), gender(), etc -
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
=== break ===
15:20 -17:00
@Bostjan Lah@Pieter Bos
ADL 2/3
there is consensus that we are committed to ADL3
need to store full-lineage of archetype specialization, name-spacing in ADL3 archetype/templates
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
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
Nov 16, 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)
WG:
@Alex Vidrean will represent EHRBase in the WG
@Rong Chen will represent Cambio both on CDS as CDR
@Mattijs Kuhlmann will join from Nedap
@Sebastian Iancu and @Pablo Pazos reviewers
@Sebastian Garde from Ocean
@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
=== Lunch break ===
=== Nedap tour ===
14:00 - 15:00
@Sidharth Ramesh
REST, SMART
brief reporting on status
IHE
-profiling for multi-EHR federation Extracts
@Erik Sundvall AQL profiling, federated AQL
ATNA logging for openEHR (@Seref Arikan )
@Bostjan Lah we already have a XDS metadata cluster archetype, saved in context of composition
IHE-UK
profiles can might do well work with us is PIX PDQ (@Pablo Pazos )
Interesting reading - sorry I couldn’t join the discussions, wrong timezone for me these days. A few comments:
I’m not clear if the SEC is currently wanting to completely ditch id-codes and just use at-codes for everything. If so, I think that is a semantic error: id-codes are the names of things to which the values stand in the IS-ABOUT relation; at-codes are values of qualities of things. An at-code can never be used in place of an id-code and vice-versa, but if they are all in the same namespace, mixing up will already does) occur. For the purpose of mapping to external terminologies, the id-codes map to LOINC. LOINC is now working with Snomed and will issue LOINC codes for everything. at-codes map to things like Snomed, ICD etc. Ac-codes map to value-set ids. If only at-codes are used like in ADL1.4, it becomes difficult to find the subset that you want to map to LOINC, or indeed to tell what kind of code it is in a query, generated code, UI form or other programming context.
I just implemented the current ADL2 spec OPT rule which puts the full archetype_id in LOCATABLE.archetype_node_id. This works fine, but loses the slot id-code, which can matter in rare cases. I see above that the decision is to keep id-codes in LOCATABLE.archetype_node_id and only put the archetype_id in LOCATABLE.archetype_details. While not technically wrong, I think it will be very misleading in OPTs, and I would suggest that if we are going to modify the rules, we would do the following in OPTs
In LOCATABLE.archetype_node_id on all nodes in the hierarchy, put archetype_id::id-code, or to be shorter, create a local id like 'aidNNN' to mean openEHR-EHR-COMPOSITION.xxxx.v1.2.3.
in LOCATABLE.archetype_details at the root points, put the inheritance lineage of the archetype / template / overlay being used at that point. On the root nodes, the archetype_id and id-code would be from the owning archetype; the filler archetype's id would be in LOCATABLE.archetype_details
This means there can be no errors on the use of id-codes down the spine of the hierarchy. Doing the above makes the OPTs a bit more bulky, but who cares - they are used for computation, not human consumption.
The real question is what goes in the data, not what goes in the OPT. My suggestion:
Systems could opt to do what they want internally. For example, it is quite likely that in Graphite we will replace any archetype code with LOINC codes in the server.
For data interchange, everyone would need to agree on a single format, but that could just be the same as what I propose for OPTs, i.e. use archetype_id::id-code; this can easily be converted to the internal form of any system on the fly.
AQL paths can still be constructed as they are today, although I am no longer in favour of id-codes in AQL queries. Instead I think we should be using key codes, as described here.
If we could add key codes, it will pave the way for asserted specialisation relationships between codes in different level archetypes, as well as remove the dependence of AQL queries on any particular coding approach, and also it can make ADL archetypes much more readable. It also provides a static basis for generating API tags.
I support moving from ODIN to YAML, that will make things easier for implementers. Since this is a non-semantic change, presumably it would be the first thing to change?
I would hope not to see ADL3 limited to BEL (basic EL) because, although it works well enough for Nedap’s current use, it’s formally deficient, as well as a lot less powerful than the full EL, which can easily replace expressions in ADL archetypes, as well as GDL guidelines. Graphite will use EL, not BEL. So I hope we can accommodate language choice.
Interesting reading - sorry I couldn’t join the discussions, wrong timezone for me these days. A few comments:
I’m not clear if the SEC is currently wanting to completely ditch id-codes and just use at-codes for everything. If so, I think that is a semantic error: id-codes are the names of things to which the values stand in the IS-ABOUT relation; at-codes are values of qualities of things. An at-code can never be used in place of an id-code and vice-versa, but if they are all in the same namespace, mixing up will already does) occur. For the purpose of mapping to external terminologies, the id-codes map to LOINC. LOINC is now working with Snomed and will issue LOINC codes for everything. at-codes map to things like Snomed, ICD etc. Ac-codes map to value-set ids. If only at-codes are used like in ADL1.4, it becomes difficult to find the subset that you want to map to LOINC, or indeed to tell what kind of code it is in a query, generated code, UI form or other programming context.
I just implemented the current ADL2 spec OPT rule which puts the full archetype_id in
LOCATABLE.archetype_node_id. This works fine, but loses the slot id-code, which can matter in rare cases. I see above that the decision is to keep id-codes inLOCATABLE.archetype_node_idand only put the archetype_id inLOCATABLE.archetype_details. While not technically wrong, I think it will be very misleading in OPTs, and I would suggest that if we are going to modify the rules, we would do the following in OPTsIn
LOCATABLE.archetype_node_idon all nodes in the hierarchy, putarchetype_id::id-code, or to be shorter, create a local id like 'aidNNN' to meanopenEHR-EHR-COMPOSITION.xxxx.v1.2.3.in
LOCATABLE.archetype_detailsat the root points, put the inheritance lineage of the archetype / template / overlay being used at that point. On the root nodes, the archetype_id and id-code would be from the owning archetype; the filler archetype's id would be inLOCATABLE.archetype_detailsThis means there can be no errors on the use of id-codes down the spine of the hierarchy. Doing the above makes the OPTs a bit more bulky, but who cares - they are used for computation, not human consumption.
The real question is what goes in the data, not what goes in the OPT. My suggestion:
Systems could opt to do what they want internally. For example, it is quite likely that in Graphite we will replace any archetype code with LOINC codes in the server.
For data interchange, everyone would need to agree on a single format, but that could just be the same as what I propose for OPTs, i.e. use
archetype_id::id-code; this can easily be converted to the internal form of any system on the fly.AQL paths can still be constructed as they are today, although I am no longer in favour of id-codes in AQL queries. Instead I think we should be using key codes, as described here.
If we could add key codes, it will pave the way for asserted specialisation relationships between codes in different level archetypes, as well as remove the dependence of AQL queries on any particular coding approach, and also it can make ADL archetypes much more readable. It also provides a static basis for generating API tags.
I support moving from ODIN to YAML, that will make things easier for implementers. Since this is a non-semantic change, presumably it would be the first thing to change?
I would hope not to see ADL3 limited to BEL (basic EL) because, although it works well enough for Nedap’s current use, it’s formally deficient, as well as a lot less powerful than the full EL, which can easily replace expressions in ADL archetypes, as well as GDL guidelines. Graphite will use EL, not BEL. So I hope we can accommodate language choice.
my 0.05 US cents…