However, despite feeling judged by the commentary , I have what appears to be a non-sensible use case where we are curious about the possibility of establishing a link between source clinical data (ie captured using the CKM archetypes designed for clinical recording) and corresponding registry data in a legacy, or integration, registry-specific archetype (either an identical data point or even an appropriate mapping to a higher level category). For example a BP of 140/90 to a category of ‘Raised BP’. Implementation is not yet decided, potentially in either the same or different CDRs.
Only limitation right now is that target is DV_EHR_URI, so as long as that kind of URI can be defined from your legacy source (and somehow understood by it) I think it’s supported.
I would have thought the default option would just be to use a DV_URI data item, which can point to anything that a URI can be obtained for. LINK as originally conceived was intended for a category of ‘semantic’ links reflecting relationships between clinical recordings, such as ‘indicated by’, ‘test result for’ and so on. I have always thought this was somewhat subjective (it’s from CEN 13606, GEHR etc), and today I would probably suggest we tighten the definition of when LINK applies, e.g. to clinical process relationships. It’s also somewhat different from just embedding a DV_URI in the data. The latter acts like an in-place reference; a LINK can hang off any larger object, e.g. the whole OBSERVATION.
@thomas.beale, a bit off-topic but perhaps it will not harm to remind here that restricting LINKs to only EHR_URIs is also an issue of https://openehr.atlassian.net/browse/SPECPR-281.
I think LINK should allow (inner) DV_URI to link only archetyped objects (including those from demographics).