Define case of updating a COMPOSITION referencing a different OPT
Raise
Analysis
Raise
Analysis
Description
I came by a test case that follows this flow:
1. commit composition 1 referencing opt1 2. commit composition 2, as a new version for composition 1 (update), that references opt2
This case is not considered con the current REST API errors, but is technically possible due programming errors or problems managing OPTs.
An initial thought is: this case should return an error, maybe a 400.
A second thought, discussed on the SEC, is: if opt2 is a compatible revision of opt1, it might not return an error and accept the update. For this case we'll need to define what is a "compatible version" for OPTs. For instance, if the opt 2 references a new version of an archetype that is compatible with the previous version of that archetype, is that a compatible revision of the opt? Not only modeling and opt management should be taken into account, but also querying. That case of the archetype updates could change associated queries to the opt, since queries can reference a specific version of the archetype.
And another consideration was about, if opt2 is a new version of opt1, but is not 100% compatible, the COMPOSITION update should also fail.
So, there is a grey area of compatible revisions that might need to be defined to add the correspondent updates to the PUT /compositon endpoint on the REST API.
Major
I came by a test case that follows this flow:
1. commit composition 1 referencing opt1
2. commit composition 2, as a new version for composition 1 (update), that references opt2
This case is not considered con the current REST API errors, but is technically possible due programming errors or problems managing OPTs.
An initial thought is: this case should return an error, maybe a 400.
A second thought, discussed on the SEC, is: if opt2 is a compatible revision of opt1, it might not return an error and accept the update. For this case we'll need to define what is a "compatible version" for OPTs. For instance, if the opt 2 references a new version of an archetype that is compatible with the previous version of that archetype, is that a compatible revision of the opt? Not only modeling and opt management should be taken into account, but also querying. That case of the archetype updates could change associated queries to the opt, since queries can reference a specific version of the archetype.
And another consideration was about, if opt2 is a new version of opt1, but is not 100% compatible, the COMPOSITION update should also fail.
So, there is a grey area of compatible revisions that might need to be defined to add the correspondent updates to the PUT /compositon endpoint on the REST API.
This is the SEC conversation https://openehrspecs.slack.com/archives/C6PBA0HNV/p1558546417002300