Relax the rule that demands uniqueness of DV_ORDINAL value
Description
Environment
duplicates
Activity
Sebastian Garde March 15, 2016 at 6:04 PM
Thanks Thomas - I then won't add this rule to CKM anymore.
Thomas Beale March 15, 2016 at 5:19 PM
Note that VCOV no longer exists in ADL2/AOM2.
Sebastian Garde March 14, 2016 at 2:18 PM
I have been asked a while ago to add this VCOV rule to CKM because the Java parser allows non-unique ordinal values, but on the other hand, tools like AE don't support it. (And taking this rule seriously this would be correct).
While I tend to think the VCOV rule is neither really necessary nor really helpful, the most important thing would be to clarify and then follow through in the tools, so we are all on the same page.
Ian McNicoll November 19, 2015 at 1:43 PM
Ian McNicoll November 19, 2015 at 1:36 PM
I have checked out this issue in AE. There are 2 problems.
Internally AE uses the ordinal number as a primary key, which must then be unique. I can fix this by making the combination of atCode + ordinal number the primary key, and can now save an ordinal with non-unique numbers.
However the Eiffel parser detects the non-uniqueness as an error and will not read the saved archetype. I will need to raise this with Peter Gummer.
Details
Details
Reporter
Labels
Components
Affects versions
Priority
Major
Currently it's not allowed to create duplicated values in a list of DV_ORDINAL instances for a given C_DV_ORDINAL. Further information see copied email communication between Thomas Beale, Ian McNicoll and Rong Chen on 2015/01/16.
Hi Ian, Thomas
We just came across another example that the current DV_ORDINAL cannot support (perhaps just the editor, please read on).
The model is called Downton Fall Risk Index. In the second component about medications, there are several ordinals with “1” as the quantity value. The Ocean’s archetype editor doesn’t really support it. See the screen shot below:
I have vague memory that this has been raised before, but couldn’t find it with JIRA. When I dig more in the specs (1.4), there wasn’t anywhere in the specs (datatypes, aom, openehr_profile) state that all dv_ordinal in a given c_dv_ordinal should have unique values. Apparently my java implementation allows duplicated values too (I checked both AOM, and ADL parser code).
So what’s the next step? If both of you can confirm this is not the an issue for the specs, then it’s a matter of bug fix in the Ocean’s archetype editor. I am not 100% sure, so please help.
Best regards,
Rong
Hi Rong,
DV_ORDINAL is a DV_ORDERED subtype, so it's defined on the assumption of being ordered, which means that each value should in theory be unique in a set, to be properly comparable.
In ADL 2, you can create an ordinal constraint with duplicate values, but of course this doesn't know anything about DV_ORDINAL as such.
ENTRY[id1] matches { –
ordinal_attr_1 matches {
DV_ORDINAL[id2] matches {
[value, symbol] matches {
[{0}, {[at2]}],
[{1}, {[at3], [at4]}],
[{2}, {[at5]}]
}
}
}
}
The real question is what happens in a real openEHR-based EHR system if any assumption is being made that all DV_ORDINALs used for a given data point are always unique. I would be very surprised if there is any enforcement of such a rule. So I think if there is any danger, it comes down to querying. Again, I suspect that a query engine wouldn't make any check to force ordinals for a given data point to be unique.
After that, the main danger is actually CDS and other computing modules that might be programmed with the unique DV_ORDINAL assumption.
I would say for practical purposes you can treat this as a AE bug, and nothing more, but can you raise an issue here (copy this email in), to be addressed in the RM (at least in documentation).
thanks
t