CONTRIBUTIONs are not LOCATABLEs so they don’t have a field to specify the rm_version.
When parsing CONTRIBUTION on POST /ehr/$id/contribution, the server doesn’t know which RM version was used to define such payload. Consider this flow:
- parse JSON CONTRIBUTION => internal JSON object
- validate JSON object with JSON schema => validation errors
- if (errors) => return error
- else => map JSON object to a list of VERSION and an AUDIT_DETAILS
- process versions and audit (validate against OPT, store, etc)
For step 2. the right JSON schema version should be chose to validate the whole CONTRIBUTION, which validates each VERSION and each VERSION.data (COMPOSITION, EHR_STATUS, FOLDER, ROLE, PERSON, …)
If there were small changes between RM versions, and the wrong JSON schema version is used, then some attributes added in newer versions won’t even be validated against the schema.
Then on step 4. the RM version can be retrieved from each VERSION.data.archetype_details.rm_version, for consistency sake, those rm_versions might be the same, and the same as the RM version of the CONTRIBUTION, which we don’t have now.
Then on step 5. when validating against the OPT, the RM version from each VERSION.data is used.
So the issue is for the initial validation against the schema. A workaround would be to get the RM version from VERSION.data, the problem is there are many, so a server that requires those RM versions to be the same, would work this way, but a server that doesn’t required that, might not work. In that case, a sensible option would be to use the minimal RM version found in VERSION.data, it’s not ideal, might leave some attributes without validation for the JSON schema validation, but there is no other way around.
I think it would be useful to have a place to put the rm_version in the JSON/XML object committed by POTS /ehr/$id/contribution, note this is not the RM CONTRIBUTION but the SM CONTRIBUTION class, the one that represents the current HTTP payload from the REST API, which is a relaxed version of the RM CONTRIBUTION, for instance, doesn’t require a CONTRIBUTION.uid to be provided (required by the RM).
I would like to know what others think, thanks!