EHR and CONTRIBUTION need a rm_version property in JSON and XML schemas
Description
Activity
Pablo Pazos June 26, 2023 at 5:25 AMEdited
Getting back to this: there is one workaround on this, when the EHR in XML/JSON has the EHR_STATUS object linked, then the rm_version could be read from the EHR_STATUS that is LOCATABLE, but if the XML/JSON follow the RM, the EHR has an OBJECT_REF to EHR_STATUS, so we don’t know to which rm_version that EHR instance in XML/JSON corresponds to.
I know the EHR RM might be fully backwards compatible, that means that the EHR could be validated and parsed using any version of the XML or JSON schemas. This holds today, but not sure if it will be true in the future. In any case, adding the rm_version to the EHR just adds formal metadata that would be useful in any processing context.
Note that there is no need of adding the field to the RM, with the field in the XML/JSON schema I think would be enough, though having it in the RM would make a 1:1 mapping to the XML/JSON representation of the EHR resource.
A similar case, added to the title, is CONTRIBUTION, which is a top-level class for the API that doesn’t have itself a rm_version field, and needs to be parsed, validated and processed accordingly to the rm_version it complies to.
When validating JSON/XML against their schemas and parsing JSON/XML to it's RM object representation, all LOCATABLE Archetype Root types (COMPOSITION, EHR_STATUS, FOLDER, PARTY concrete subclasses) have archetype_details.rm_version so the validator and parser can know which schema version to use and which RM version to instance when parsing. EHR can also be serialized in XML/JSON, but since it's not LOCATABLE, a schema validation process or a parser doesn't have any information about the RM version. So the validation could give the wrong result and the parser could parse an EHR for RM 1.1.0 as RM 1.0.2. I think we can solve this without changing the RM, just the schemas, by adding a required property rm_version to the EHR type. Note supporting multiple RM versions is something required by the Conformance Verification Framework, since we need to adapt to whatever RM version is implemented in the system that we are checking for conformance. And it might be needed for SDKs and other openEHR tools that work with multiple RM versions.