Change LINK.target to DV_URI

Description

Change LINK.target to DV_URI

Consider that DV_EHR_URI represents ehr scheme space - what to do about URIs pointing to parties?

Activity

Show:
Thomas Beale
April 29, 2020, 12:38 PM

From SEC call 27 Mar 2020

:

:

Options:

  • add DV_OPENEHR_URI class

  • just specify DV_URI

  • or treat ‘ehr’ scheme space as universal openEHR

Better LINK URI examples ( ):

ehr:work-plans/4ff64a96-7800-4fab-9076-776dc55cb743
ehr:tasks/380daa09-028f-4beb-9803-4aef91644c2a
tp:m-tasks/b726cd9f-aa1e-454f-93fd-575c4b05e30c

DIPS LINK URI ( ):

ehr:compositions/4ff64a96-7800-4fab-9076-776dc55cb743??

Runtime TP Work Plans - not in EHR space.

Thomas Beale
May 26, 2020, 8:20 AM
Edited

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.

Matija Polajnar
May 27, 2020, 5:40 AM

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.

Thomas Beale
May 27, 2020, 7:18 AM

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.

Thomas Beale
June 15, 2020, 3:11 PM

and to work out IANA registration approach.

Reporter

Thomas Beale

Raised By

Sebastian Iancu

Components

Affects versions

Configure