# DV_DATE definition mismatch **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2009-11-13 11:09 UTC **Views:** 2 **Replies:** 9 **URL:** https://discourse.openehr.org/t/dv-date-definition-mismatch/14941 --- ## Post #1 by @system Hello everybody, I have detected what it seems a mismatch between the DV_DATE definition of the reference model and the ADL parser/AOM model specifications. At the RM, the DV_DATE value is defined as a String constrained as an ISO8601 pattern. This is both at the RM specification and at the XML Schema. Following the ADL/AOM specifications, something such as (this code has been generated by the Ocean Archetype Editor) DV_DATE matches { value matches {yyyy-??-XX} } will be parsed as a C_Primitive_Object of the type Date (in fact, DvDate at the java parser that I use). The problem then is that the DvDate type parsed does not correspond to the String definition of the RM, generating then a non valid archetype that does not correspond to the RM. There are two possible solutions. Or the RM is changed to represent correctly the DV_DATE value as a "xs:date" type with the appropriate ISO8601 facet or the archetypes should take the form value matches {"yyyy-??-XX"} to be parsed as a String according to the RM definition. I'm right with this? --- ## Post #2 by @williamtfgoossen In a message dated 13-11-2009 12:22:04 W. Europe Standard Time, damoca@gmail.com writes: > There are two possible solutions. Or the RM is changed to represent correctly the DV_DATE value as a "xs:date" type with the appropriate ISO8601 facet or the archetypes should take the form > value matches {"yyyy-??-XX"} > to be parsed as a String according to the RM definition. shouldn't this be yyyymmdd format and why not the harmonized datatypes for electronic health records / exchange according to ISO 21090? That is in particular developed for semantic interoperability of data type formats and based on OpenEHR, CEN and HL7 examples. It seems a bit silly to use another older standard for this. Met vriendelijke groet, Results 4 Care b.v. dr. William TF Goossen directeur De Stinse 15 3823 VM Amersfoort email: Results4Care@cs.com email: williamtfgoossen@cs.com telefoon +31 (0)654614458 fax +31 (0)33 2570169 Kamer van Koophandel nummer: 32133713 --- ## Post #3 by @thomas.beale --- ## Post #4 by @Karl_Holzer Hi all, Me and my colleague are trying to create ehr extracts in form of instances of different openehr archetypes \(body mass index for example\) as XMLs\. Our problem is that we don't know if the structure of our xml is absolutely right\. So, does anyone have valid xml\-instances of the body mass index or similar archetypes \(with anonymised or some kind of dummy data\)? The most useful file for us would start from the composition class\. We know the \.xds files but can't figure out the right structure\. Thanks in advance, Karl --- ## Post #5 by @Heath_Frankel3 Hi David, There is nothing wrong in the openEHR specifications or the Ocean Archetype Editor’s construction of the ADL representation of an ELEMENT of type DV_DATE. The RM specifies the DV_DATE class as having a value attribute of type string that represents an ISO8601 date, which supports partial dates, e.g. “1934-05” or “1934” (also note that “193405” is also a valid ISO8601 representation of “1934-05”). These partial dates are not supported by XML’s xs:date and hence it has not been used in the schema. The constraint specified in the ADL fragment you have provided below is a further constraint on this ISO8601 representation, as specified in [http://www.openehr.org/releases/1.0.2/architecture/am/adl.pdf](http://www.openehr.org/releases/1.0.2/architecture/am/adl.pdf) section 5.4.6.1. This particular constraint indicates that the month is optional and day is not to be provided, so valid date must be a partial date like the examples above. What Java Parser are you using? Are you sure that the parser is not producing a DvDate object that represents the value attribute of the ELEMENT, which itself has a value attribute which has a constrained string representation of a partial date? Regards Heath Heath Frankel Product Development Manager Ocean Informatics heath.frankel@oceaninformatics.com +61 (0) 8 7127 5574 --- ## Post #6 by @Heath_Frankel3 Hi Karl, Have a look at http://southern.oceanehr.com/Ehrview15/?ehruri=ehr://6421a888-e1cb-4741-b629 \-e69a92c2812a/fc995f12\-e8bf\-4c86\-b292\-0434bef0c9ad::B9D93A96\-52C0\-4401\-8DC8\- 882413140145::1\. You can login using username test and password test\. Click the OpenXML button in the bottom right hand corner to see the underlying XML\. Regards Heath Heath Frankel Product Development Manager Ocean Informatics heath\.frankel@oceaninformatics\.com \+61 \(0\) 8 7127 5574 --- ## Post #7 by @Heath_Frankel3 Please note that the composition instance provided below may be using archetypes that are either older than those available in CKM or not available at all\. However it should serve your purpose of seeing what an openEHR composition that contains a BMI looks like in XML\. Heath --- ## Post #8 by @system Dear Heath, The problem I’m focusing is an incorrectness regarding the dual model methodology rules. If in a reference model we have an attribute of the type “String”, an archetype constraining it must be a C_String instance from the archetype model. If we had an attribute of the type “Date”, then the correct AOM class to constraint it would be a C_Date. The problem here is that in the reference model we have a “String” attribute (the ‘value’ attribute of the DV_DATE) but the generated archetypes use a C_Date class to constraint it instead using a C_String. Here is the mismatch. Following the principles of the dual model approach we cannot consider that a valid archetype with regard to the underlying reference model. 2009/11/16 Heath Frankel <[heath.frankel@oceaninformatics.com](mailto:heath.frankel@oceaninformatics.com)> --- ## Post #9 by @Karl_Holzer Thanks Heath, you made our day\.\.\. \-\-\-\-\-\-\-\- Original\-Nachricht \-\-\-\-\-\-\-\- --- ## Post #10 by @thomas.beale I only just noticed this post from a few months ago..... the problem highlighted by David is a slight anomaly in the modelling, because the concrete type of DV_DATE is indeed a String, but one whose pattern is constrained to be an ISO8601 Date. We constrain it with a C_DATE which should technically constrain some object of 'DATE' type. In teh ADL 1.5 spec this has been corrected so that C_DATE is defined explicitly as a constrainer for ISO8601_DATE. I realise the types do not quite match up, and this is because of the anomaly of a) using a strinng to represent a proper type - which is what ISO8601 does, and is also convenient since a String is easier to manage than some structured type b) but treating itas if it were a proper type. Getting around this would require making the ISO8601_DATE types etc direct subtypes of the String class, which is not a particularly desirable thing to do. In the ADL 1.5 Archetype workbench, I have a substitution table for String/ISO8601 types, to deal with this anomaly. - thomas beale [details="(attachments)"] ![OceanInformaticsl.JPG|183x82](upload://2lcnRHcC3QqDv6AeaDZuo8M9Qlv.jpeg) [/details] --- **Canonical:** https://discourse.openehr.org/t/dv-date-definition-mismatch/14941 **Original content:** https://discourse.openehr.org/t/dv-date-definition-mismatch/14941