We've started to see "updated-end-date" tags appearing in some Things. So far only Conditions and apparently not in all cases. A sample fragment is below:
<thing> <thing-id version-stamp="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx">xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</thing-id> <type-id name="Condition">7ea7a1f9-880b-4bd4-b593-f5660f20eda8</type-id> <thing-state>Active</thing-state> <flags>0</flags> <eff-date>2013-06-04T10:32:13.868</eff-date> <data-xml> <condition> <name> <text>Dementia</text> </name> <onset-date> <structured> <date> <y>2013</y> <m>1</m> <d>4</d> </date> </structured> </onset-date> <status> <text>Current: Currently has this</text> <code> <value>active</value> <family>wc</family> <type>condition-occurrence</type> </code> </status> <stop-date> <structured> <date> <y>2013</y> <m>6</m> <d>4</d> </date> </structured> </stop-date> </condition> <common> <extension source="ABP-DLS-Condition"> <category> <text>Dementia</text> <code> <value>dementia</value> <family>dls</family> <type>ltcterms</type> </code> </category> </extension> </common> </data-xml> <updated-end-date>2013-06-04T00:00:00</updated-end-date> </thing>
As far as I can tell this is not within the XML spec for Things but is being added by HealthVault in error. Is anyone else seeing this? (If it matters, this is on the US PPE site)
It would have been nice if the documentation said this *before* I asked the question (I had checked the documentation -- in the form of https://platform.healthvault-ppe.com/platform/XSD/thing.xsd -- before observing that it is "not within the XML spec for Things" ) I observe that this schema has now changed. It would be even better if we developers were being told about upcoming changes -- with documentation -- before they make it into the real world, even if that means the PPE environment sometimes running the code for the next release, or the creation of another environment that always tracks the next release. (Even better: mark these changes in the documentation/XSDs so we know what has changed and when)
I am guessing from your referenced article, the fact that the schema makes this an optional field and our direct observation that this field hasn't been set for existing data where a possible source field exists, even though there are a set of rules for doing this when the thing is updated. As such it will trickle through as and when changes occur, which makes it a little useless for querying against -- or is the information being brought in using those rules at the query level but not in the returned data?