I created an archetype with an ORDINAL attribute and mapped terminologies into the options. Using that archetype, I created a template and tried to validate it against the openEHR schema specifications.
During validation, I noticed that one mandatory element, <value> under DV_TEXT, is missing. Both the archetype and template were created using the Better Archetype Designer tool.
This is the validation error I got:
‘value’ expected instead of ‘defining_code’
Do you have any idea why this mandatory element is missing in the OPT file?
I’m coming back to this - sorry we all missed it @Yasitha_Thilantha , as the issue has come back again, as part of FerroEHR
OPT 1.4 export from Archetype Designer omits mandatory DV_CODED_TEXT.value on DV_ORDINAL symbols — requesting confirmation · Issue #3395 · rubentalstra/FerroEHR · GitHub reported by @Sophie
My gut feeling is that the .opt generated by AD is correct - we should not be adding the DV_CODED_TEXT/value constraint, as this is inherently language-neutral.
I think the problem is that the XSDs expect a full DV_CODED_TEXT in the context of ‘symbol’ - I can see that in similar situations, a C_QUANTITY_LIST openEHR profile has been created to allow 'magnitude` to be omitted.
I assume the same applies to DV_SCALE
@ian.mcnicoll thanks for picking this up again, and @Sophie thanks for the report on the FerroEHR tracker (OPT 1.4 export from Archetype Designer omits mandatory DV_CODED_TEXT.value on DV_ORDINAL symbols — requesting confirmation · Issue #3395 · rubentalstra/FerroEHR · GitHub).
Ian, on the model we agree. AOM 1.4 defines C_ORDINAL.list as a list of ORDINAL, and ORDINAL.symbol is a CODE_PHRASE (Appendix A: “Terminology code providing the Ordinal’s symbol”). A code, no text. The rubric sits in term_definitions, per language, which is what 0|[local::at0005] has meant since ADL 1.4.
The OPT 1.4 XML format is a different matter. Its only released definition is OpenehrProfile.xsd in AM/Release-1.4 (the same file in the 1.0.2 and 2.0.0 ITS-XML bundles). That schema serialises C_DV_ORDINAL.list and assumed_value as the RM type DV_ORDINAL, so the symbol is a DV_CODED_TEXT with a mandatory value. The schema already made C_QUANTITY_ITEM.magnitude optional for this exact reason and never did it for ordinals. Model and schema disagree, and a document without the element is invalid against the only definition the format has.
FerroEHR validates against that schema and accepts exactly what it admits. It refuses the Archetype Designer export and accepts the CKM one, because CKM writes an empty <value/> (valid: xs:string, empty allowed).
I have written the model/schema disagreement up on our tracker: upstream(ITS-XML): OpenehrProfile.xsd requires DV_CODED_TEXT.value on a C_DV_ORDINAL symbol, while AOM 1.4 ORDINAL.symbol is a CODE_PHRASE with no text · Issue #3401 · rubentalstra/FerroEHR · GitHub. It has not gone to the ITS-XML tracker yet. The fix would be your proposal: make value optional inside the profile for ordinal symbols, as magnitude already is, or model the list with an ORDINAL-shaped type whose symbol is a CODE_PHRASE. Both work with every OPT that already carries a rubric. Until then an OPT 1.4 exporter has to write <value/> the way CKM does.
@Yasitha_Thilantha, the validator you used was right about the released schema. The disagreement is between the schema and the model.
Thanks Ruben,
I’ve done a bit more digging and a quick summary
-
The spec says that DV_CODED_TEXT/value is xs: string but the XSD says NoEmptyStrings so perhaps CKM’s output is not strictly legal.
-
The original spec has the DV_ORDINAL list as DV_CODED_TEXT but this was subsequently updated to C_CODE_PHRASE and, in fact the BMM has an Ordinal class which is very close to what we were prposing for C_ORDINAL_ITEM.
-
I’m pretty sure that most ?none of the existing tools or CDRs are not using the .xsd to validate .opt files, otherwise this would have come to light earlier.
-
My guess is that the CKM .opt generation is based on code that predated the spec change while AD/ Archie and therefore Ehrbase are basically using BMM as the source of truth.
We should still get the XSD fixed as we know that it is valuable for other tooling but there is an argument to relax the XSD validation at template upload for your CDR. The XSD fixes might take a little time to figure out the best route to maintain backwards compatibility.
@sebastian.garde @sebastian.iancu @matijap @birger.haarbrandt any thoughts/advice re how.if .opts are validated at ingest via the REST API/ other tooling?
I agree this an issue we will need to tackle. How exactly - I don’t know right now (there is a lot of information written above which I need to process), but is likely that the XSD are outdated, and the JSON-schemas are not reach enough. I would first make sure BMM is the way it shoudl be (if is not already). If we don’t have a SPECPR for this, can some one create it pleaae?
Like @sebastian.iancu, I have to admin that I am not sure I have processed the whole thread adequately yet, but would like to make the following preliminary general comments:
-
It seems to me that having the value populated here with a localised text is redundant and introduces a language dependency on the opt which we don’t really want - nor need?
-
Generally speaking, the (design time) opt cannot fulfill the (runtime) requirement that all mandatory elements exist and fulfill all constraints. Even if value is declared as mandatory (and non-empty), this cannot always mean it is mandatory in the archetype or template and thus opt. Take DV_TEXT.value or even DV_CODED_TEXT.value(as the data type of an element itself). You cannot (usually) fix them to a specific value at design time, even though they will be mandatory in data. If you take the data type constraints as the basis for validation, there will probably be no opt that validates?
I think we agree on the issue and that the XSD should not demand a populated DV_CODED_TEXT.value
The Ocean .opt generator gets around this by creating
<value> </value> (a space)
which complies with the
<xs:element name="value" type="NonEmptyString"/> in DV_TEXT.
The PDF specs say
Which is IMO correct
and BMM
C_ORDINAL:
name: C_ORDINAL
documentation: 'Constrainer class for Ordinal data.'
ancestors:
- C_DOMAIN_TYPE
properties:
list: !P_BMM_CONTAINER_PROPERTY
name: list
documentation: 'Value set of allowed Ordinals in the constraint.'
type_def:
container_type: List
type: ORDINAL
cardinality:
lower: 0
upper_unbounded: true
ORDINAL:
name: ORDINAL
documentation: 'Constrainer object representing a single Ordinal value.'
properties:
symbol: !P_BMM_SINGLE_PROPERTY
name: symbol
documentation: "Terminology code providing the Ordinal's symbol."
is_mandatory: true
type: CODE_PHRASE
value: !P_BMM_SINGLE_PROPERTY
name: value
documentation: 'Ordinal value.'
is_mandatory: true
type: Integer
We could change the XSD to match the BMM and spec definition which would allow the Better .opt to validate but the Ocean .opt would then fail, so I’m inclined to make the XSD a choice of DV_CODED_TEXT or ORDINAL to keep the Ocean approach valid in order to limit disruption.
DV_SCALE has the same issue.
I’ll add CRs in JIRA and pull request in Github ITS-XML
