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.