Change LINK.target to DV_URI
Consider that DV_EHR_URI represents ehr scheme space - what to do about URIs pointing to parties?
From SEC call 27 Mar 2020
add DV_OPENEHR_URI class
just specify DV_URI
or treat ‘ehr’ scheme space as universal openEHR
Better LINK URI examples ( ):
DIPS LINK URI ( ):
Runtime TP Work Plans - not in EHR space.
In thinking about this issue, there’s no solution that corresponds cleanly to the requirement and causes no impact. Candidate approaches:
relax the specification of DV_EHR_URI to mean ‘any openEHR URI’, including demographics, ?task planning? - this doesn’t break any data, and requires only minimal changes to existing software to handle new openEHR URIs; however, the class name DV_EHR_URI now doesn’t correspond that well to its more general purpose.
add a type DV_OPENEHR_URI between DV_URI, and specify it to be for any scheme space used in openehr, including ‘ehr’, ‘demographic’, ‘tp’, whatever (into the future); change LINK.target to be of this type. This will cause more impact in software, and might or might not in data, depending on whether the type ‘DV_EHR_URI’ appears in LINK instances.
If the second approach doesn’t break anyone’s data (or at least, if the break is tolerable according to the implementation owners), I’d possibly suggest that. Otherwise the first one seems the more obvious.
I vote for the second approach. There is only one problem I foresee: if there are any compositions in any of the various JSON (canonical or simplified) formats lying around (or hard-coded into applications as data placeholders), the second approach might need additional logic to automatically determine the correct subtype to use if we will change any fields from type DV_EHR_URI to its new parent DV_OPENEHR_URI. Otherwise deserialisation will fail for old documents where the type attribute was not mandatory because DV_EHR_URI had no subtypes.
Right - that’s exactly the potential problem I was thinking of. If the dev groups of Better / DIPS / Code24 / Ocean / EhrBase … could give us an impact assessment and/or preference, we’ll know which way to go.
and to work out IANA registration approach.