Agreed to have just one WG for ADL/AOM/templates; treat ‘ADL2 transition’ as a openEHR-wide discussion - potentially X-board forum and/or f2f meeting (similar to Braunschweig).
Some adjustments to other WG scopes.
Question on conformance WG responsibilities.
Add WG for RM, since not otherwise covered, including ‘episode’ modelling.
REST API for openEHR Tags package (ITEM_TAG). Questions to the SEC: 1. Would the SEC be comfortable with letting the REST WG detail something along the following points? 2. What thoughts would you like to send along into that work?
Background: In e.g. the Swedish openEHR RFI, TAGs combined with ABAC have surfaced as one of the most interesting ways to solve complex Swedish legal requirements regarding access control. In use cases like that one would like want/need to have some ways of adding tags in the same atomic transaction as adding/modifying COMPOSITIONs (and likely other versioned objects).
A JSON (and likely an XML) serialisation format for ITEM_TAG needs to be specified. (Perhaps it already exists?)
An API to modify ITEM_TAGs independently of changes to versioned objects (for non-atomic use cases) is needed. Perhaps some validation rules also, e.g. not allowing tagging of non-existing objects?
One possible way to modify the REST spec to optionally allow combined tag+composition atomic modifications is to allow contributing also ITEM_TAG objects in the .../contribution POST call.
Also it would be good if the …/composition API endpoint had some convenient way of optionally setting/modifying tags atomically together with the composition creation/change, perhaps via http headers following existing patterns, so something like openEHR-ITEM_TAG: key="my_nice_key", value="...", target_path="..." (ITEM_TAG.target would be the current COMPOSTION and ITEM_TAG.owner would be the current EHR)
Another important thing is how to standardise the API (headers?) for using tags for filtering and querying (as defined in the tag “semantics” section). Adding stuff to AQL right now might be contentious, but allowing optional filtering via http-headers in the …/query API could be a fairly easy thing to define and add as anoptional feature to the REST ITS. Perhaps DIPS, Better and others using already using TAGS could describe what filtering operations you support and how?