meeting chat

From Bjørn Næss, DIPS to Everyone: 02:24 PM
I open-sources my doc generator for WebTemplate to ASCIIDOC: https://www.npmjs.com/package/wt2doc
It will get confused if it gets some Markdown somewhere
We should agree on one formalism.
From freshEHR Crew to Everyone: 02:28 PM
I think we need to support both @bjorn. Asciidoc is better but Markdown has way more general community uptake and is probably good enough for most projects
e.g https://freshehr.github.io/dhi-proms/dhis/DHIS2-retrieving-an-ehrId/
anyway - I forked your code to add Markdown output as one of my holiday projects :)
From Bjørn Næss, DIPS to Everyone: 02:28 PM
Guess you have to have two weekends to get tables working in MD :-)
From freshEHR Crew to Everyone: 02:29 PM
simples
From Bjørn Næss, DIPS to Everyone: 02:29 PM
For us markdown is preferered. There are no good .NET Libraries for asciidoc.
But we use asciidoc for all user/relase/etc documentation in DIPS.
From Bjørn Næss, DIPS to Everyone: 02:36 PM
New class
CODE_PHRASE_HIER extends CODE_PHRASE
children: CODE_PHRASE_HIER
From Bjørn Næss, DIPS to Everyone: 02:44 PM
Or even simpler, New attribute on CODE_PHRASE

selectable: true/false
CODE_PHRASE.indentation (default = 0, 1,2,3)

From Pieter Bos to Everyone: 02:46 PM
But CODE_PHRASE is not used in archetypes to indicate hierarchy, just in actual RM instances.
From Bjørn Næss, DIPS to Everyone: 02:49 PM
That is a great change!
or even easier - add a new optional attribute "layout" which defines the structure of the codes
From Pieter Bos to Everyone: 02:49 PM
If you want to do it in archetypes, you probably need to add a new concept to the terminology - the archetype terms are language dependent, and these relationships probably shouldn’t. Maybe a new property on the value sets in ADL 2 could work, indicating hierarchies independently from the translations.
From Bjørn Næss, DIPS to Everyone: 02:50 PM
Yes - the same thing I was thinking Pieter
From Diego to Everyone: 02:51 PM
it would be something like ac0003:is_a:ac0001
or even allow for codes in the operator
ac0003:ac000X:ac0001
From Pieter Bos to Everyone: 02:52 PM
yes, or a tree:
We now have:
value_sets = <
["ac1"] = <
id = <"ac1">
members = <"at1", "at2", "at3", ...>
>
>
From Bjørn Næss, DIPS to Everyone: 02:52 PM
[
{
"code": "at001",
"children": [
{
"code": "at0002"
},
{
"code": "at0003"
}
]
},
{
"code": "at004"
}
]
From Diego to Everyone: 02:53 PM
maybe something like
From Pieter Bos to Everyone: 02:53 PM
So adding a hierarchy property there could help, but only if we hierarchies are limited within a value set
From Diego to Everyone: 02:54 PM
value_sets = <
["ac1"] = <
id = <"ac1">
members = <"at1", "at2", "at3", ...>
relationships=<"at1:is_a:at3","at2:is_a:at_3">
>
>

From Bjørn Næss, DIPS to Everyone: 02:54 PM
All the ideas/suggestions above is backward compatible IMHO.
That's a good thing.
From Pieter Bos to Everyone: 02:56 PM
The value_sets addition only is if your parser accepts additional ODIN attributes, but easy enough to add
FHIR hierarchy meaning, that isn’t actually used in the fhir terminology service (!): http://hl7.org/fhir/R4/valueset-codesystem-hierarchy-meaning.html
they define is_a, part of, classified with and grouped by. I think snomed has something similar defined?
From Diego to Everyone: 02:56 PM
I always assumed that most parsers of them just got as a hashmap, with methods to get the standard ones
From Pieter Bos to Everyone: 02:57 PM
We map to actual objects if defined in the AOM, which it is here - but of course we can map to hashmaps, and we can configure it to just ignore additional properties
From Diego to Everyone: 02:59 PM

they define is_a, part of, classified with and grouped by. I think snomed has something similar defined?
They have the is_a hierarchy and then a pletora of atributes, probably not easily translated to other terminologies
allowed attributes change depending on which concept is your focal concept
From Bjørn Næss, DIPS to Everyone: 02:59 PM
Diego -we discussed a similar topic 4 years ago: https://openehrspecs.slack.com/archives/C2CD84RUL/p1474025119000021
From Diego to Everyone: 03:05 PM
I can only see things up to 20th October 2019 :(
From Me to Everyone: 03:06 PM
https://openehr.atlassian.net/wiki/spaces/spec/pages/624754994
From Diego to Everyone: 03:07 PM
guys I got to go. Read you later!
From Bjørn Næss, DIPS to Everyone: 03:08 PM
Where are we on the agenda now ?
From Me to Everyone: 03:08 PM
nope ...
From Bjørn Næss, DIPS to Everyone: 03:08 PM
Ah - the terminology service. Sorry.
From Bjørn Næss, DIPS to Everyone: 03:19 PM
A suggestion to add some terms related to AQL

select c/name/value as foo from composition c
c/name/value --> identified path
c --> identifier
name/value --> path
foo --> alias
some explanation on terms - I meant.
From Pieter Bos to Everyone: 03:21 PM
I have to leave unfortunately. Thanks for the good discussions. And I look forward to the ADL/AOM 2.1.0 reviews at https://openehr.atlassian.net/projects/SPECAM/versions/11068/tab/release-report-all-issues ;)
From Thomas Beale to Everyone: 03:22 PM
thx
From Pieter Bos to Everyone: 03:23 PM
Discourse topic about the review process: https://discourse.openehr.org/t/adl-release-2-1-0-to-review/1080 . Bye!
From freshEHR Crew to Everyone: 03:23 PM
Thx Pieter
From Sebastian Garde to Everyone: 03:27 PM
I've created this filter based on the SEC-TODO filter: https://openehr.atlassian.net/issues/?filter=11165

It also includes "in review" issues that nobody has accepted yet.
From Thomas Beale to Everyone: 03:28 PM
nice one!
aha - currently it's private - there's a setting you need to make it public
From Sebastian Garde to Everyone: 03:28 PM
now!
From freshEHR Crew to Everyone: 03:33 PM
@Sebastian G!!! - nice one.
From Bjørn Næss, DIPS to Everyone: 03:33 PM
An open question: Will Applications in eHealth be able to switch backends so easy? I guess there will be some process setting up the Applications.
From freshEHR Crew to Everyone: 03:34 PM
It will depend on the application. Simpler apps definitely. We have already done a fair bit of that
From Bjørn Næss, DIPS to Everyone: 03:35 PM
I assume you will need some API_KEY i.e. to Connect to an external CDR from another organisation. And as part of that you will agree on the conformance steps?
If I where responsible for the data I would need to check what kind of AQL's you had in mind.
From freshEHR Crew to Everyone: 03:36 PM
We do need to demo a bulk import/export which includes contributions and ?? link resolution
https://kangax.github.io/compat-table/es6/
From Thomas Beale to Everyone: 03:36 PM
Yes - this - https://specifications.openehr.org/releases/SM/latest/openehr_platform.html#_admin_service
needs specification work
From freshEHR Crew to Everyone: 03:37 PM
Birger's guys are working on the import/import
From freshEHR Crew to Everyone: 03:45 PM
https://kangax.github.io/compat-table/es6/