Are ITEM_TAGs wrapped in CONTRIBUTIONs?

Specifications were written before ITEM_TAGs were introduce so it is natural that the CONTRIBUTION mostly mentions that COMPOSITION, EHR_STATUS, FOLDER are committed with it. In other places specifications mention that CONTRIBUTION.versions can be used for “top level objects” and ITEM_TAG is a top level object.

I just want to be 100% sure I’m implementing the REST API v1.1.0 correctly by committing ITEM_TAGs with CONTRIBUTION (for PUT https://{baseUrl}/v1/ehr/{ehr_id}/composition/{uid_based_id}/tags).

ITEM_TAGs can be associated with the COMPOSITION via openehr-item-tag or openehr-version-item-tag request headers at the time of creation. I guess in this case ITEM_TAGs from the request headers are added to CONTRIBUTION.versions next to the COMPOSITION?

The original debate was along the lines of: are tags something that can be independently added by any party post facto to an EHR or not? For example, imagine some cancer research group wants to tag data from last 5-10 years for some study; another group wants to do similar but for other conditions. Teaching faculty want to enable data tagging for student use. And so on.

None of that is wanted in the EHR - it’s external use. So it’s not committed ‘into’ the EHR, and would never appear in a Contribution. It may still be versioned, just elsewhere.

Then the question is: ok, are there uses for tagging ‘in’ the EHR, i.e. that would be committed as part of it, even if committed (much) later on? We might imagine some AI agent running through old EHRs and tagging specific diagnoses of some kind as being ‘suspect’ due to a later discovery (my favourite is always H Pylori). I don’t know what uses/users might want to do this, but we can presume that there are potentially some.

So the tagging capability probably needs to serve both. I built the first (probably still current) model, very much a thumbnail, which doesn’t adequately show how these two cases would be satisfied. But if improving it today, I would make it handle both.

I meant to say: I didn’t invent the model, it was 100% the result of discussions from mainly Better & DIPS, and a bit of ?Code24 - sorry don’t remember now. But what is there is something that is (in my view) very initial, but that the group agreed to. I (think I) remember Better saying they handle the case of independent tagging, i.e. the first case - and possibly that all their tags are of tat variety.

Anyway, above, I am just trying to lay out the two broad requirements as I see them.

From reading discussions on this forum, I was under the impression that item tags would be used for “clinically related” tagging. So, this applies to the “in” EHR use case (your 2nd use case).

I’m afraid that item tags will be used for both scenarios unless it’s explicitly documented that they shouldn’t be used for the 2nd use case (in specifications and especially in the REST API).

A list of ITEM_TAGs can be associated with the COMPOSITION when POST endpoint is made. This might lead people to believe that item tags are also versioned.