SPECITS-77 add support for tags#105
Conversation
…openEHR-** request headers
| The `uid_based_id` can take a form of an OBJECT_VERSION_ID identifier taken from VERSION.uid.value (i.e. a `version_uid`), | ||
| or a form of a HIER_OBJECT_ID identifier taken from VERSIONED_OBJECT.uid.value (i.e. a `versioned_object_uid`). | ||
| The former is used to delete the tags a particular (target) version of the COMPOSITION version (e.g. one identified by `8849182c-82ad-4088-a07f-48ead4180515::openEHRSys.example.com::1`), | ||
| whereas the later (e.g. an identifier like `8849182c-82ad-4088-a07f-48ead4180515`) is be used to delete the tags of the target VERSIONED_COMPOSITION container, |
|
|
||
| This will return an empty list when there is no matching ITEM_TAG associated with any target within given EHR. | ||
|
|
||
| More then one ITEM_TAG may be associated with a single target, in which case they are uniquely identified |
|
|
||
| This will return an empty list when there is no ITEM_TAG associated with the given target. | ||
|
|
||
| More then one ITEM_TAG may be associated with a single target COMPOSITION or VERSIONED_COMPOSITION, in which case they are uniquely identified |
There was a problem hiding this comment.
more then -> more than (in about 20 places throughout this PR)
|
|
||
| ## openehr-item-tag | ||
|
|
||
| The `openehr-item-tag` header is available all change-controlled resources (e.g. COMPOSITION, EHR_STATUS, FOLDER, etc.). |
There was a problem hiding this comment.
Grammatically incorrect, missing preposition. Perhaps "... is available on all ..."?
| Retrieves the list of ITEM_TAG resources associated with any target VERSION or | ||
| VERSIONED_OBJECT within the EHR identified by `ehr_id`. | ||
|
|
||
| This list can be filtered by the given one or more `tag_key`, `tag_value`, `tag_target_path` query parameters. |
There was a problem hiding this comment.
Right now, at Better we only support search by tag key, OR a combination of tag key and value. I don't think it makes sense to separate the two. We also do not support a search by target path; those can only be observed.
I know it could fairly easily be implemented, yet I'm wondering if it makes any sense to really support all combinations of searches like this suggests.
| or a form of a HIER_OBJECT_ID identifier taken from VERSIONED_OBJECT.uid.value (i.e. a `versioned_object_uid`). | ||
| The former is used to get the tags of a particular (target) version of the COMPOSITION version (e.g. one identified by `8849182c-82ad-4088-a07f-48ead4180515::openEHRSys.example.com::1`), | ||
| whereas the later (e.g. an identifier like `8849182c-82ad-4088-a07f-48ead4180515`) is be used to get the tags of the target VERSIONED_COMPOSITION container, | ||
| which semantically are equivalent to tags targeting the latest version. |
There was a problem hiding this comment.
Is this true, and does that mean that retrieving a set of ITEM_TAGs for a VERSIONED_OBJECT will always return the same result as retrieving a set of ITEM_TAGs for its last VERSION? And what happens if a user separately issues commands to set some tags for the VERSIONED_OBJECT and one to set tags for the last VERSION? The ITEM_TAG in RM has target which can point to either of those, and I guess the system would make separate entries for each.
To be clear, I'm not trying to align this with Better's current implementation but rather to make it sensible and clear. Given the fact that right now we only tag VERSIONs, this would work in our advantage (if VERSIONED_OBJECT and its last version are basically synonymous), but I don't think that was meant to be the case?
| - $ref: ../parameters/path/key.yaml | ||
| responses: | ||
| '204': | ||
| $ref: ../responses/204_because_deleted.yaml |
There was a problem hiding this comment.
Right now at https://specifications.openehr.org/releases/ITS-REST/development/ehr.html#tag/ITEM_TAG/operation/composition_tags_delete it says that 204 confirms that the tag was logically deleted. Tags are not versioned, nor logically deleted, as far as I know. I can't find that text anywhere in this PR, so it might be that the compiled version is an old one and the issue had already been dealt with.
| @@ -0,0 +1,28 @@ | |||
| operationId: ehr_tags_get | |||
| summary: Get EHR tags | |||
There was a problem hiding this comment.
This request is akin to retrieving all compositions from an EHR: we usually don't want to do that because there will be simply too much data. Do we really want to expose this kind of functionality for an entire EHR?
|
|
||
| ## openehr-item-tag | ||
|
|
||
| The `openehr-item-tag` header is available all change-controlled resources (e.g. COMPOSITION, EHR_STATUS, FOLDER, etc.). |
There was a problem hiding this comment.
Not that I'm particularly keen on having tags on folders, but they are versioned objects which is why you mentioned here. However, I don't see description of this header in the API, but you did amend the composition and EHR-status related API endpoints with a mention of this header...
2 participants
No description provided.